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

Bruce Dubbs bruce.dubbs at
Sat Oct 18 19:21:52 PDT 2008

Jeremy Huntwork wrote:
> Chris Staub wrote:
>> Another problem (not really related to this, but it does also involve
>> m4) is that, as the book is now, m4 in /tools is not linked to /tools. 
>> Either m4 needs to be built again in /tools sometime after the toolchain 
>> adjustment, or the host system's m4 can be used for GCC and the m4 in 
>> /tools can be moved later in the build order.
> This is what I was saying in my other post. :)
> So, to sum up, we have two problems:
> 1. m4 in chapter five doesn't link against /tools
> 2. m4 in chapter six is built to late to avoid hard-coded paths to 
> /tools/bin/m4 showing up in autotools scripts.
> I personally think that we can trust the host system to have a working 
> m4 for the first pass of gcc,

If that is so, what is the minimum version?  We will also need to add a check 
for m4 in the host requirements section:

$ m4 --version|head -n1
GNU M4 1.4.4

The oldest version on is 1.4.1 dated June 2004.

   -- Bruce

BTW, there was a new version released 11 Oct 2008 - 1.4.12.

It builds with configure && make && make check && make install.
Three tests were skipped:

cannot tell stack overflow from crash; consider installing libsigsegv
Skipping test: multithreading not enabled
SKIP: test-lock
Skipping test: multithreading not enabled
SKIP: test-tls

* Noteworthy changes in Version 1.4.12 (2008-10-10) [stable]
   Released by Eric Blake, based on git version 1.4.11.*

** Fix regression introduced in 1.4.4b where using `traceon' could delete
    a macro.  This was most noticeable with `traceon(`traceon')', but
    would also happen in cases such as `foo(traceon(`foo'))'.

** Fix regression introduced in 1.4.7 where `m4 -N9' died with an assertion

** Fix regression introduced in 1.4.11 where `defn' died with an assertion
    failure on a traced but undefined macro.

** New `-g'/`--gnu' command-line option overrides `-G'/`--traditional'.
    For now, the environment variable POSIXLY_CORRECT has no effect on M4
    behavior; but a future release of M4 will behave as though --traditional
    is implied if POSIXLY_CORRECT is set (this future change is necessary,
    because in the current release, there is no way to disable GNU
    extensions that conflict with POSIX without the use of a non-POSIX
    command-line argument).  Clients of M4 that want to use GNU extensions,
    even when POSIXLY_CORRECT is set, should start using the -g command-line
    argument, even though it is currently a no-op if -G did not appear
    earlier in the command line, so that the client will not break in the
    face of an upgraded m4 and a POSIXLY_CORRECT execution environment.

** The `-L'/`--nesting-limit' command-line option now defaults to 0 for
    unlimited on platforms that can detect and deal with stack overflow.  On
    systems that lack alternate stack support, such as Cygwin, and on
    systems that do not obey the POSIX semantics for distinguishing stack
    overflow from other exceptions, such as Linux, you can optionally
    install the libsigsegv library (version 2.6 or newer recommended) to
    enhance m4's ability to accurately report stack overflow:

** A number of portability improvements inherited from gnulib.

More information about the lfs-dev mailing list