Mail Archives: djgpp/2003/08/15/15:13:27
>Are you sure you really should have used this --with-headers option?
I have built this target a few times now and it has always required
this option, but it is possible that something has changed.
>
>> GNU C++ version 3.3 (i586-pc-msdosdjgpp)
>> compiled by GNU C version 3.2 (Mandrake Linux 9.0 3.2-1mdk).
>
>
>Hmmm... that seems to contradict what you wrote further up (quote
>moved down by me:)
I agree. I set the environment variable CC ahead of time. I am going
to redo this build and check the makefiles to see what compiler is
actually being used by binutils, gcc, and libstdc++ as they build.
>> ignoring nonexistent directory
>> "/usr/local/lib/gcc-lib/i586-pc-msdosdjgpp/3.3/../../../../include/c++/3.3"
>
>This and the following ones appear to be the core of your problem:
>*all* the places where it's looking for C++ includes are nonexistent,
>it seems, leaving only C-only paths:
Yes, but what causes the incorrect paths to be part of the linker
search?
>
>> /usr/local/compiler/cross/djgpp-2.04/lib/gcc-lib/i586-pc-msdosdjgpp/3.3/include
>> /usr/local/compiler/cross/djgpp-2.04/i586-pc-msdosdjgpp/sys-include
>> /usr/local/compiler/cross/djgpp-2.04/i586-pc-msdosdjgpp/include
I did verify that c programs compile and run on the target platform.
>> The header in question, <iostream>, does exist in:
>> /usr/local/compiler/cross/djgpp-2.04/include
>
>That means something's gone seriously wrong. C++ headers should never
>be in there.
i agree. i was looking at a prior working build for this target and
c++ headers were in $prefix/include/c++/3.x
Im going to do this all again, isolate why the mandrake compiler was
used, and then go from there. Additionally, I am going to build gcc
separate from libstdc++ and see if this sheds any light.
Thanks,
Charles
- Raw text -