This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fenv.h not found?


Greetings, All --

On Wed, Oct 20, 2010 at 6:11 AM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> All,
>
> On Wednesday 20 October 2010 08:15:18 Anthony Foiani wrote:
>> So it seems that headers for libstdc++ get installed into the sysroot
>> (where they are probably not needed), rather than in the cross-compile
>> directory itself.
>
> The issue is that:
> - build a cross-toolchain
> - use that cross-toolchain to build a full-blown system for your target
> - use that cross-toolchain to build a native compiler (same version as in
> Âthe cross-toolchain) to run on your target (which I call a cross-native,
> ÂI'm ready to use a better name if you have one)
> - you want that compiler to use the same C/C++ headers and libraries as the
> Âone from your cross-toolchain, or else you are in trouble.
> So you want to be able to copy the sysroot to your target's rootfs and get
> all that is needed to build natively on your target.
>
> I understand "sysroot" as being the "system root" that holds all system
> headers and libraries for the target. If it does not contain everything,
> it becomes non-trivial to add native compiling on the target...

I don't disagree.  :)

In my case, I'm not planning on doing any compilation on the target
itself; I want to cross-compile everything, and just run it on the
target.  Having the includes in the sysroot doesn't bother me; I was
only looking for a way to make sure that the *host* compiler could
find them...

(I believe that either Arnaud or Ralf also argued for the use case
where the compiler on the target might actually *not* match the
compiler vendor or version used for the cross-compilation; I'll let
them chime in if that's the case.)

> Well, libstdc++ is part of gcc, so I call that a gcc issue. ;-)

True.

>> Anyway, installing a symlink like so seems to do the trick:
>> cd /opt/cross/platforms/foo/xtools/powerpc-e500v2-linux-gnuspe
>> chmod u+w .
>> ln -s sys-root/usr/include .
>> chmod u-w
>
> OK, I'll revert the gxx-include-dir hack.
> Then the PREFIX/TARGET/include symlink will go, so gcc is free to install
> its stuff in there.

Not quite sure I parse that.

What I can say is that I managed to compile zlib, bzip2, boost,
libxml2, apache, and my own code base successfully by using the
attached .config and then creating that one symlink.

> I want this issue to be resolved before next release.
> Can we come to an agreement that the above is the way to go?

Depending on exactly what you mean by "symlink will go".  :)

I'm very happy right now.  Thanks again to everyone for all your work!

Best Regards,
Tony

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]