Does the M4 package need to be identified as a "host requirement"?

Randy McMurchy randy at
Sat Oct 11 11:38:59 PDT 2008

DJ Lucas wrote:
> Randy McMurchy wrote:
>> Jeremy Huntwork wrote these words on 10/06/08 10:45 CST:
>>> I would think that adding it to the Host Requirements page would be 
>>> slightly preferable. Here's my thinking:
>>> We already have bison as a host req. Bison depends on m4, so most 
>>> distros I know will have m4 installed as a dependency of bison. Even 
>>> building bison from source requires that you first build m4, anyway. So 
>>> I tend to think of Bison and M4 going hand in hand. Why add an extra 
>>> thing to build if by far the majority of systems will have already had 
>>> m4 installed due to the bison req?
>> I lean to agreeing with Jeremy on this one. If M4 is probably present
>> on the host (due to it being required by bison), then it is one less
>> package that needs to be built in Chapter 5.
>> We need to resolve this issue, so let's make some sort of decision
>> one way or another. Other suggestions are welcome.
> It has to built in Chpater 5 for the chapter6 GMP regardless.  When is 
> the only question.  I see no need to add a host requirement if m4 can be 
> built right after binutils' first pass.  I suppose it could be moved way 
> up in the chain for Chapter 6, but I though that we wanted all tools 
> compiled by the last built version of gcc and binutils.  Obviously, 
> BinUtils, GMP and MPFR are exceptions to this rule (but are compiled by 
> the same version of the target compiler type and libs), should M4 be an 
> exception also?

Sorry for quoting the entire previous post, but the material is
all relevant, and we need to make a decision. Here's the choices:

1. Use Jeremy's suggestion that since Bison is already a prerequisite,
which mean that m4 is probably on the host as well, simply disregard
the issue and leave the Chapter 5 M4 installation in its alphabetical

2. Make M4 a prerequisite.

3. Move the M4 Chapter 5 installation to be right after the Binutils
Pass 1 installation.

Let's make a decision and put this one to bed.


More information about the lfs-dev mailing list