Mail Archives: djgpp/2003/08/15/19:00:55
On 15 Aug 2003 16:37:11 GMT, Hans-Bernhard Broeker >
>> Configured with: ../gcc-3.3/configure
>> --prefix=/usr/local/compiler/cross/djgpp-2.04
>> --target=i586-pc-msdosdjgpp
>> --with-headers=/usr/local/compiler/cross/djgpp-2.04/i586-pc-msdosdjgpp/include
>
>Are you sure you really should have used this --with-headers option?
yes I am reasonably certain at this point.
I was able to get the compiler to work with the c++ library by copying
the headers. e.g. moving what was erroneously dumped by make into
$prefix/include into the correct location of $prefix/include/c++/3.3/
why this happened, I am still looking into. fortuately i had another
system with an older build of the cross compiler, so that I could
compare directory structures.
>
>> GNU C++ version 3.3 (i586-pc-msdosdjgpp)
>> compiled by GNU C version 3.2 (Mandrake Linux 9.0 3.2-1mdk).
I still dont know why this compiler was called. When I repeated all
of my steps, this didn't happen again. It is possible I built from a
different shell than I was in when I ran configure.
>> 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:
still some nonexistant directories listed..
strangely enough, I just built a fresh native gcc-3.3.1 and it has
some of these too =/ but it works nevertheless.
Now that I think of it, every gcc compiler I have ever built has had
some "nonexistant directories" in its search path. Is there no way to
remove them???
>
>> /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
>
>This hints at an installation problem. Do you have an <iostream> file
>anywhere below /usr/local/compiler/cross/djgpp-2.04?
yes
>Im quite sure they shouldn't --- the path they start in is an addition
>to your --prefix, not an alternative.
this is what is supposed to happen, but not what is happening for
every entry in the SEARCH_PATH
>
>> 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.
yes, I suspect in the patching process of the gcc-3.3 sources.
I verified this by applying the patches myself as well as by building
with the prepatches source from delorie.com.
Both builds resulted in the c++ library headers being dumped in
$prefix/include, where the correct nesting would be
$prefix/include/c++/3.3
so far, it seems that manually copying the files and directories is an
effective workaround.
Charles
- Raw text -