make install can't find aclocal

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



make install can't find aclocal



I'm trying to compile a code to run in parallel on a supercomputer. I know that others have compiled this code to run on the same computer, but for some reason I am having trouble even when using the same methodology as them. For now I'm just trying to compile the code to run in serial as that should be easier to troubleshoot.



configure seems to work correctly.
However make install returns the following:


> make install

CDPATH="$ZSH_VERSION+.:" && cd .. && /bin/sh /home1/username123/code123/config/missing aclocal-1.13 -I ./config -I /home1/username123/code123/build-tools/aclocal -I /usr/local/share/aclocal
aclocal-1.13: error: couldn't open directory '/usr/local/share/aclocal': No such file or directory
Makefile:534: recipe for target '../aclocal.m4' failed
make: *** [../aclocal.m4] Error 1



aclocal is indeed not located at /usr/local/share/aclocal, it is located at /usr/bin/aclocal - but as /usr/bin is in my path, I don't understand why the location is an issue.





How did you get the code onto the supercomputer in the first place? What do you do before make install? It is somewhat surprising that make is looking for such a file in the first place -- it is used only for maintaining the project's Autotools-based build system, and should not be necessary for building or installing the project itself.
– John Bollinger
Aug 6 at 15:11



make install


make





I copied the source code onto the supercomputer, then "configure" (with default settings for the purpose of easy troubleshooting), and then "make install". When I originally tried compiling the code (including additional libraries and MPI), I received some odd errors regarding git and libtools which also didn't seem to make sense in the context of building & installing.
– cbrian
Aug 6 at 16:19






I'm afraid that's not specific enough, but it's enough for me to say that what you should do is copy the distribution tarball to the target computer, unpack it there, change to the package directory, and then proceed with configure and make. Additionally, be sure that extraction of the tar file preserves the timestamps within (this is the default for every tar I have experience with).
– John Bollinger
Aug 6 at 17:42


configure


make


tar


tar





It may also help to tell configure to --disable-maintainer-mode, but not all configure scripts support this.
– John Bollinger
Aug 6 at 17:43


configure


--disable-maintainer-mode


configure





I tried copying over the tarball to the supercomputer and unpacking it there. That fixed the issue, the code compiled correctly. I did not understand Autotool's reliance on time stamps. Thank you for your help @JohnBollinger !
– cbrian
Aug 6 at 19:35





1 Answer
1



As has been made clear in comments on the question, the problem was that the project sources were copied onto the target system in a way that failed to preserve their original timestamps. The Autotools, through make, use file timestamps to determine which files are out of date, and in particular, Autools-generated Makefiles contain rules for rebuilding the build system itself that can be triggered this way.


make


Autools


Makefile



It is not ordinarily necessary or desirable to rebuild an Autotools project's build system, except in conjunction with actually performing maintenance on it. It is often the case, in fact, that the necessary support for that is not available locally. To avoid the build system thinking that it needs to rebuild itself, it is important to preserve the file timestamps from the distribution archive. For some packages, it also works to pass the --disable-maintainer-mode argument to the configure script, but by no means do all Autotools configure scripts support that.


--disable-maintainer-mode


configure


configure



The archive extraction tools for the typical archive formats in which Autotools-based packages are distributed do, by default, preserve timestamps when unpacking, so the ordinary procedure of


tar xzf foo-1.2.3.tar.gz


cd foo-1.2.3


configure; make; make install



normally does the right thing. Substituting something else for (1), however, such as copying the unpacked source tree from somewhere else, may cause the package to think it needs to rebuild the build system. If that works correctly then it's no big deal, but it is not uncommon that it doesn't. That's what happened here, and following the standard procedure described above solved the problem.






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

make 2 or more post in bootsrap

Store custom data using WC_Cart add_to_cart() method in Woocommerce 3

Firebase Auth - with Email and Password - Check user already registered