Re: c++ includes not getting searched for correctly?

[Ralf Corsepius <rc040203 at freenet dot de>]

 On 10/08/2010 06:54 PM, Yann E. MORIN wrote:
> Bryan, All,
>
> On Friday 08 October 2010 01:15:07 Bryan Hundven wrote:
> > After making the following symlink:
> > ln -s ${CT_SYSROOT_DIR_PREFIX}/sys-root/usr/include
> > ${CT_SYSROOT_DIR_PREFIX}/include
> > Everything works fine.
> Good to know we have a workaround.
>
> But I'm not happy with it, though. An absolute path makes the toolchain
> non-relocatable, and this is a Bad Thing (TM). At least, make it a relative
> symlink.
>
> Also, I believe that gcc should be somehow taught where to look fot the
> headers. It is already properly looking at sysroot/usr/include for C headers
> and looking there for C++ should be the default as well.
No. You'd end up with a broken toolchain, because the headers/libs 
inside of the sysroot do not correspond to your cross toolchain's GCC 
(e.g. they might be part of a different version of GCC or correspond to 
completely different setup). As I tried to express before, libstdc++ and 
its auxiliary libraries (on some platforms, libstdc++ comes with other 
helper libraries) are internal GCC libraries. They depends upon GCC, 
they are GCC-version-dependent, etc. etc.

You may, however install those c++-headers/libs into your sys-root (and 
to remove the original ones before), if you want to use a sys-root's 
contents at target runtime (e.g. when using an nfs-mounted root as 
"sys-root" of your cross-compiling system. Think about mounting a 
solaris machines "/" into a linux machine's cross-toolchain's sys-root). 
This is basically what your symlinks do in a very brutal fashion.

Ralf





--
For unsubscribe information see http://sourceware.org/lists.html#faq