Bug 8307 - libstdc++ fails to compile because of fixincludes headers
: libstdc++ fails to compile because of fixincludes headers
Status: RESOLVED INVALID
Product: gcc
Classification: Unclassified
Component: libstdc++
: 3.2
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
:
:
:
  Show dependency treegraph
 
Reported: 2002-10-21 22:26 UTC by Pete Gonzalez
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
Host: i686-pc-cygwin
Target: arm-agb-elf
Build: i686-pc-cygwin
Known to work:
Known to fail:
Last reconfirmed:


Attachments
stdlib.h (1.23 KB, application/octet-stream)
2003-05-21 15:17 UTC, Pete Gonzalez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pete Gonzalez 2002-10-21 22:26:00 UTC
This bug has been reported before in various forms:

http://gcc.gnu.org/ml/gcc/2002-02/msg00644.html
http://gcc.gnu.org/ml/gcc/2002-04/msg00908.html
http://gcc.gnu.org/ml/gcc/2002-06/msg01602.html

The occurs because build-gcc/gcc/include/stdlib.h is being used instead of the real "stdlib.h" from NewLib.  The "fixed" header file is missing many definitions which libstdc++-v3/include/cstdlib is looking for.  The problem can be fixed by deleting the aforementioned file, which is created by the "fixincludes" script.

I poked around in inclhack.def, but was unable to figure out where stdlib.h is coming from; it clearly is not derived from the NewLib version.  Maybe fixincludes is doing a search+replace on the wrong file?  I've attached a copy of the erroneous stdlib.h for reference.

Release:
GCC 3.2 / NewLib 1.10.0 / Binutils 2.12.1

Environment:
Cross compiler from i686-pc-cygwin for target arm-agb-elf

How-To-Repeat:
Unfortunately it would be difficult to reproduce the exact compiler environment.
Comment 1 Pete Gonzalez 2002-10-21 22:26:00 UTC
Fix:
1. Run "make"
2. When compilation of libstdc++ fails, delete build-gcc/gcc/include/stdlib.h
3. Resume "make"
Comment 2 Richard Earnshaw 2003-01-31 17:02:40 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: I regularly build a GCC/Newlib/binutils toolchain and don't see this problem.  Are you configuring using the "--with-headers=..." option?
Comment 3 Pete Gonzalez 2003-02-15 15:20:42 UTC
From: Pete Gonzalez <gonz@ratloop.com>
To: gcc-gnats@gcc.gnu.org,gcc-bugs@gcc.gnu.org,nobody@gcc.gnu.org,
 gcc-prs@gcc.gnu.org,gonz@ratloop.com,Peter.Barada@motorola.com
Cc:  
Subject: Re: other/8307: libstdc++ fails to compile because of
  fixincludes headers
Date: Sat, 15 Feb 2003 15:20:42 -0500

 >I regularly build a GCC/Newlib/binutils toolchain and don't see this
 >problem. Are you configuring using the "--with-headers=..." option?
 
 Yes, but my environment is a bit unusual.  I am building an ARM
 cross-compiler under Cygwin, using a modified version of this kit:
 
          http://www.io.com/~fenix/devkitadv/
 
 I think this is just an unusual setup that hasn't been tested by
 whoever maintains the "fixincludes" code.  I don't think it's
 specific to Cygwin, because at one point I was able to reproduce
 the bug under Debian Linux.  If someone wants to volunteer to
 debug it, I could probably create a Makefile that reproduces the
 problem in one of those environments.
 
 Thanks,
 -Pete
 
Comment 4 Wolfgang Bangerth 2003-05-14 21:14:33 UTC
State-Changed-From-To: feedback->open
State-Changed-Why: Feedback provided long ago
Comment 5 Dara Hazeghi 2003-06-08 07:57:23 UTC
Hello,

would it be possible for you to verify that this problem still occurs with gcc 3.3? Thanks,

Dara
Comment 6 Pete Gonzalez 2003-06-17 16:10:23 UTC
I was able to confirm the problem under Debian Linux, using the latest GCC 3.3 
sources but with patches applied.  I need to verify that the patches are not 
the cause of the problem, however it will take me a couple weeks to allocate 
the time for this.

-Pete
Comment 7 dank 2003-07-20 21:42:15 UTC
This is the kind of stuff I had to dance around for weeks when I
was writing http://kegel.com/crosstool, my build scripts for
gcc/glibc cross-compilers.  There might be some ideas there for
you on how to force it to not do fixincludes.  I wish I had time
to add newlib support to my build scripts, but I haven't had a
business reason to yet...
Comment 8 Nathanael C. Nerode 2003-08-05 01:53:14 UTC
Possiblility 1. Fixincludes/fixproto is simply running on the wrong set of
headers (this can be checked by looking at the value of SYSTEM_HEADER_DIR in the gcc
Makefile, which should refer to the correct header directory).
Possibility 2. A fixincludes hack is demolishing stdlib.h.  (Run fixincludes
by typing 'make stmp-fixinc' in the gcc/ directory, and see if there are lines
saying 'Fixed: stdlib.h'.  Those hacks will be the possible culprits.)
Possibility 3. It's being trampled post-fixincludes, by fix-header.c/fixproto.
(this seems unlikely, but is possible).

The solutions are quite different in the three cases, so if it could be determined for sure which one was going wrong, it would help a lot in 
tracking this down.
Comment 9 Dara Hazeghi 2003-08-24 18:19:18 UTC
Just a reminder that this bug is still in WAITING, and will be closed, if we
don't get feedback about 
it. I'm unable to see this with gcc mainline, cvs newlib and binutils, though
thanks to PR11476, I 
must disable multilibs to build.
Comment 10 Andrew Pinski 2003-09-19 15:59:09 UTC
No feedback in 3 months and Dara could not reproduce this.
Comment 11 Pete Gonzalez 2003-09-21 10:36:06 UTC
Sorry I didn't respond sooner.  I am happy with this outcome.
I've been able to workaround the bugs by deleting the bad
headers, and the problem seemed to have been fixed in a
recent 3.4 snapshot.