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

[Tushar Teredesai]

I think it would be a good idea to use "*make install-no-fixedincludes"
instead of "make install" during Chapter 6 gcc installation.*

[Greg Schafer]

Post by Tushar Teredesai
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?

Greg

[unknown]

Post by Greg Schafer

Post by Tushar Teredesai
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).
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.

Billy

[Greg Schafer]

Post by unknown
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.

I haven't built the gcc head lately. I stopped once they started merging in
the development branches (basic-improvemnts & pre-compiled headers) and was
waiting for it to settle down.

I don't understand your exact problem. Care to elucidate the specifics?

Greg

[unknown]

Post by Greg Schafer

Post by unknown
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.

I haven't built the gcc head lately. I stopped once they started merging in
the development branches (basic-improvemnts & pre-compiled headers) and was
waiting for it to settle down.
I don't understand your exact problem. Care to elucidate the specifics?

It's the variable argument macros, here's the first error I get when
trying to rebuild the compiler with itself:

/home/billyoc/../../gcc/gcc/gengtype.c:39: undefined reference to `__builtin_va_start'

The code in gengtype.c is:

void
error_at_line VPARAMS ((struct fileloc *pos, const char *msg, ...))
{
VA_OPEN (ap, msg); /**** LINE 39 ****/
VA_FIXEDARG (ap, struct fileloc *, pos);
VA_FIXEDARG (ap, const char *, msg);

fprintf (stderr, "%s:%d: ", pos->file, pos->line);
vfprintf (stderr, msg, ap);
fputc ('\n', stderr);
hit_error = 1;

VA_CLOSE (ap);
}

Now, the VA_OPEN macro is defined in /usr/include/ansidecl.h, and
that's where I dead end with the problem, I haven't found how this is
failing yet.

Billy

[Greg Schafer]

Post by unknown
It's the variable argument macros, here's the first error I get when

Hmm, I just updated and kicked off a build. Now in stage 2 and seemed to
have got past the point of your failure..

Post by unknown
/home/billyoc/../../gcc/gcc/gengtype.c:39: undefined reference to `__builtin_va_start'

Hmm, __builtin_va_start is defined in gcc's own internal header stdarg.h

You sure you doing make bootstrap?

Another thing. It could be a flex/bison thingy. You using contrib/gcc_update
to update your local checkout? If not, perform a fresh checkout manually,
then cd into gcc and "contrib/gcc_update" and rejoice as it adjusts the
timestamps for you.

Greg

[Greg Schafer]

Post by Greg Schafer

Post by unknown
It's the variable argument macros, here's the first error I get when

Hmm, I just updated and kicked off a build. Now in stage 2 and seemed to
have got past the point of your failure..

And now finished a full bootstrap and make check:-

http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01038.html

Sorry I cannot shed any more light on why it fails for you.

Greg

[unknown]

Post by Greg Schafer

Post by Greg Schafer

Post by unknown
It's the variable argument macros, here's the first error I get when

Hmm, I just updated and kicked off a build. Now in stage 2 and seemed to
have got past the point of your failure..

Yeah, me too, fresh update and I'm back in business.

Post by Greg Schafer
And now finished a full bootstrap and make check:-
http://gcc.gnu.org/ml/gcc-testresults/2003-01/msg01038.html
Sorry I cannot shed any more light on why it fails for you.

Thanks for the OT excursion. :)

Billy

[unknown]

Post by Greg Schafer

Post by Tushar Teredesai
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).
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?
Greg

I don't understand all these side effects, but here is a little input.
Check out the README at /usr/lib/{system}/3.2.1/include.

In my case, fix includes "fixed" openssl/bn.h and kept a copy (not sure if
original or fixed) at the above location. Well, OpenSSH found the copy and
exits with an unresolved symbol. Remove the copy, solve the problem.

Hope this helps.

Larry

[Tushar Teredesai]

Post by Greg Schafer

Post by Tushar Teredesai
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).

Yep, but most use the same commands to upgrade. Maybe just a note to the
effect giving them an option. BTW, I have been using no-fixincludes
since it was first discussed on this list without any problems.

Post by Greg Schafer
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?

Is it possible to run fixincludes after installation of gcc and install
the fixed headers in a seperate directory?

I remember doing a diff sometime back, didn't turn up anything significant.

[unknown]

Post by Greg Schafer
I agree, but not for the example you quoted.

I too think we should stay away from the fixincludes script for all the same
reasons.

I'm not volunteering to figure out why gcc's fixed headers make packages fail
to compile, but I am very interested in learning what the reasons are though.

For now I too vote replacing 'make install' with 'make
install-no-fixedincludes"

Any objections?

[Billy O'Connor]

[Billy O'Connor]

[Larry Lawrence]

[Billy O'Connor]

[Dagmar d'Surreal]

Post by Tushar Teredesai
I think it would be a good idea to use "*make install-no-fixedincludes"
instead of "make install" during Chapter 6 gcc installation.*

I'm of this same opinion since it seems that the "fixed" headers appear
to make gcc immune to _any_ changes to your include files--whether you
want them or not. I wasn't very amused to find out about the problem
with openssl considering I thought I'd altered my gcc builds to omit the
fixed headers until Larry posted about it. I would have _never_ looked
down in there to find the solution except as an accident with grep and
find.

[Gerard Beekmans]

[R***@pha.com.au]

Post by unknown

Post by Greg Schafer
I agree, but not for the example you quoted.

I too think we should stay away from the fixincludes script for all the
same reasons.
I'm not volunteering to figure out why gcc's fixed headers make packages
fail to compile, but I am very interested in learning what the reasons

are

Post by unknown
though.
For now I too vote replacing 'make install' with
'make install-no-fixedincludes"
Any objections?

OK, I'm doing a slightly alternative build to you guys
(specifying --enable-version-specific-runtime libs, as I also install
gcc-2.95.3 for the kernel build ), but you may want to check that your c++
headers get installed.

( check /usr/gcc-lib/SYSTEM-TRIPLE/3.2.1/include where system triple
will most likely be i686-pc-linux-gnu for most of you )

I had no c++ directory...

Creates a few issues with the ncurses build.

Solution was after make install-no-fixedincludes
cd SYSTEM-TRIPLE/libstdc++-v3
make install

Maybe its just me, but I wouldn't count on it...

Regards
Ryan Oliver

[Kelledin]

Post by R***@pha.com.au

Post by unknown
For now I too vote replacing 'make install' with
'make install-no-fixedincludes"
Any objections?

OK, I'm doing a slightly alternative build to you guys
(specifying --enable-version-specific-runtime libs, as I also
install gcc-2.95.3 for the kernel build ), but you may want to
check that your c++ headers get installed.
( check /usr/gcc-lib/SYSTEM-TRIPLE/3.2.1/include where system
triple will most likely be i686-pc-linux-gnu for most of you )
I had no c++ directory...
Creates a few issues with the ncurses build.
Solution was after make install-no-fixedincludes
cd SYSTEM-TRIPLE/libstdc++-v3
make install
Maybe its just me, but I wouldn't count on it...

It's not just you.

I just started a new LFS myself. First time through with gcc, I
did it pretty much "by the book". I got the c++ headers in
/usr/include/c++, all was well.

Later I rebuilt gcc with --enable-version-specific-runtime-libs
(my more usual method of building gcc). I missed my c++
headers. :( Thankfully, Ryan's solution worked.

Should we make a note of this in the book? Technically, when
following the book to the letter, this problem doesn't crop up.
Still, I think it at least deserves a comment, as I would
suspect that Ryan and I aren't the only ones who use
--enable-version-specific-runtime-libs.

[unknown]

Post by Kelledin
suspect that Ryan and I aren't the only ones who use
--enable-version-specific-runtime-libs.

Neither do I. So it was confirmed that passing that option causes c++ headers
not to be installed, right?

[Gerard Beekmans]

[Greg Schafer]

Post by unknown

Post by Kelledin
suspect that Ryan and I aren't the only ones who use
--enable-version-specific-runtime-libs.

Neither do I. So it was confirmed that passing that option causes c++ headers
not to be installed, right?

I haven't really played with "-enable-version-specific-runtime-libs" yet but
I'm starting to lean back towards a patch to disable the fixincludes.

Sure, it's a hassle to apply the patch, but the net result is a touch
cleaner and the build is a smidgen quicker as well.

Greg

[Seth W.Klein]

Post by Greg Schafer
[...]
I'm starting to lean back towards a patch to disable the fixincludes.
Sure, it's a hassle to apply the patch, but the net result is a touch
cleaner and the build is a smidgen quicker as well.

I hope you will. I've seen too many discussions of breakage with
that makefile target to be happy using it.

cheers,
Seth W. Klein

[R***@pha.com.au]

Definitely confirmed...