musl-cross-make
musl-cross-make copied to clipboard
Why is MAKEINFO set to false?
I understand that MAKEINFO=false
works, but MAKEINFO=true
works better for scripts that fail on error.
I don't recall the original motivation, but GCC and binutils make it really painful to suppress generation of info documentation during build and this was part of it. Note that there are multiple cases: into tools not installed, info tools installed but an old version that doesn't work, or recent info tools installed, and in all of those cases we want info docs not to be built.
I see.
While MAKEINFO=false
may guarantee that no docs will be built, it has higher chances of breaking the build (particularly binutils) on some hosts (when a false value is returned), also MAKEINFO=true
will have the exact same effect without breaking the build, because all that variable does (MAKEINFO
) is specify the path to the makeinfo
executable to satisfy autotools, and it's better if true
was returned as it'll both do nothing (like false
), and satisfy the tests.
If, and based on experimentation, MAKEFILE=false
was chosen for a good reason, I suggest at least adding a note that says if you encounter an error when building binutils, please use this instead MAKEFILE=true
.
Thanks for your time.
Did you encounter such an issue?
I'm guessing they hit https://sourceware.org/bugzilla/show_bug.cgi?id=25491. binutils 2.34 accidentally dropped the pregenerated info files from the tarball.
Maybe, but mcm is intended to work with the case where the info source has been edited (since in the past some of the patch files we've needed did that) and as far as I know it worked. I don't like making random changes like @firasuke proposed here without actually understanding whether something is broken, and if so, why. If it actually is broken, a correct fix might be more involved.
I apologize for being vague.
I want to clarify that I'm not facing any issues with the current version of software that mcm supports, and that building both a cross and native toolchains (followed by a chroot setup) works perfectly fine.
I've actually tried a local copy of mcm with the latest gcc and binutils, along with a script of mine that replicates what mcm does for cross toolchains, and both failed with binutils 2.34 when using MAKEINFO=false
with the following:
...
if false --split-size=5000000 --split-size=5000000 -I "/home/firasuke/Projects/test2/sources/binutils/binutils-2.34/binutils/doc" -I "/home/firasuke/Projects/test2/sources/binutils/binutils-2.34/binutils/../libiberty" -I "/home/firasuke/Projects/test2/sources/binutils/binutils-2.34/binutils/../bfd/doc" -I ../../bfd/doc -I /home/firasuke/Projects/test2/sources/binutils/binutils-2.34/binutils/doc \
-o binutils.info `test -f 'binutils.texi' || echo '/home/firasuke/Projects/test2/sources/binutils/binutils-2.34/binutils/doc/'`binutils.texi; \
then \
rc=0; \
else \
rc=$?; \
$restore $backupdir/* `echo "./binutils.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
make[3]: *** [Makefile:474: binutils.info] Error 1
make[3]: Leaving directory '/home/firasuke/Projects/test2/builds/binutils/binutils/doc'
make[2]: *** [Makefile:1134: info-recursive] Error 1
make[2]: Leaving directory '/home/firasuke/Projects/test2/builds/binutils/binutils'
make[1]: *** [Makefile:3632: all-binutils] Error 2
make[1]: Leaving directory '/home/firasuke/Projects/test2/builds/binutils'
make: *** [Makefile:853: all] Error 2
Specifying MAKEINFO=true
seems to fix this problem, also downgrading the binutils version seems to fix it as well.
I also believe that this is related to: https://sourceware.org/bugzilla/show_bug.cgi?id=25491
Do you have the MAKE += INFO_DEPS= infodir=
and MAKE="$(MAKE)"
parts like I have? Those were found to be needed to really stop all the info generation behavior.
I haven't updated the gist I mentioned above, but yes I'm facing the above error (and the build stops as I have set -e
on) when using:
MAKE="make MULTILIB_OSDIRNAMES= INFO_DEPS= infodir= ac_cv_prog_lex_root=lex.yy MAKEINFO=false"
but once I switch MAKEINFO=true
, it continues just fine.