Using m4 in the temporary tools and installing it after autoconf in chapter 6 makes a tool of a autoconf link to the m4 in /tools

Bryan Kadzban bryan at
Sat Oct 18 16:58:32 PDT 2008

Hash: RIPEMD160

Rick Houkes wrote:
> Making m4 part of the temporarily toolchain and installing it after
> autoconf makes a tool of autoconf called autom4te link to the m4 in
> /tools instead of a m4 that would be part of a finished system.

Um, m4 doesn't provide any shared or static libs; how can anything link
to it?  And looking at autom4te, it's a Perl script; how can that link
to anything?

Oh, I see: it hardcodes the path to the m4 binary.  OK, terminology
confusion, never mind, you're right.

We can fix this by moving m4 (back?) up before autotools in chapter 6.
Actually if bison does the same thing (it seems to hardcode the path,
though you can override it by setting the shell M4 variable, just like
autom4te), then I'd say right after iana-etc is a good place.  Plus
that's in alphabetical order among this early set of mostly-parallel

Oh, I see what happened (looking at the svn log of chapter06.xml) -- the
dependency info ("bison/autoconf depend on m4") wasn't entirely clear
that they depended because they hardcoded paths, not only because they
required some m4 binary to be available somewhere.  For package order
changes, it might be worthwhile to double-check the "must be installed
before:" lists in the current book's Appendix C.  (That is, check both
whether the package you're moving must be installed before anything
else, and whether anything else must be installed before it.  Those
lists are the closest thing I can find to "these other packages hardcode
the path to bits of this package".)

OTOH, this has happened, what, twice?  Maybe it's not worth worrying
about trying to fix the cause of the breakage, and just fix the
breakage.  :-)
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the lfs-dev mailing list