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] |
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] |