Ch6 gcc: Don't run fixincludes [Fwd from blfs-support: Re: openssl-0.9.7 and openssh-3.5p1]

Billy O'Connor billyoc at
Wed Jan 22 16:17:03 PST 2003

gschafer at (Greg Schafer) writes:

> On Wed, Jan 22, 2003 at 05:52:23PM -0600, Tushar Teredesai wrote:
>> I think it would be a good idea to use "*make install-no-fixedincludes" 
>> instead of "make install" during Chapter 6 gcc installation.*
> I agree, but not for the example you quoted.
> LFS Ch 6 gcc is installed before any third party libs like openssl therefore
> the fixincludes process doesn't get the chance to "fix" the openssl headers.
> It would only become an issue if gcc gets reinstalled at a later date (when
> all the 3rd party libs are already installed).
> Sidenote Rant:
> It annoys me that on a brand new LFS using all the latest packages,
> fixincludes tries to "fix" what it thinks are broken headers. Why are they
> broken? Should someone knowledgable look at the affected headers and see if
> the fixes are correct then submit bugs upstream? If the headers are not
> broken then should bugs be submitted to the fixincludes maintainer? Any
> volunteers?

This is becoming more and more of a problem for me, I used to be able
to build and install gcc(HEAD) in a ~/gcctest directory and use it to
test things out, and to make sure there were no unpleasant surprises
in store for us with the next version of gcc.  But I haven't been
able to do this lately, the only way I've been able to build
gcc(HEAD) since we went to gcc-3.2.1 has been to build it on a
RedHat/Mandrake box.  :(  Quite a nuisance.


Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list