Re: GCC support libraries and sysroot

[Khem Raj <raj.khem@gmail.com>]

On Sun, Mar 25, 2012 at 8:16 AM, Paul Smith <paul@mad-scientist.net> wrote:
> On Sun, 2012-03-25 at 16:36 +0200, Yann E. MORIN wrote:
>> > It causes GCC to install support
>> > libraries like libgcc_s.so into the sysroot instead of the default
>> > location which makes it tricky to replace the sysroot later.
>>
>> What I don't really understand is why gcc does not install those libs
>> in the sysroot. Why are those libs so special that they are "support
>> libraries" and they do not deserve being installed in the sysroot?
>> Yes, that's a real question I do not have the answer to.
>
> In my environments (although I'm not using crossgcc, I have my own
> makefile to build a "crosstools suite") I have the same situation as
> Michael.  I have a single compiler toolsuite, and a number of different
> sysroots.  I create these sysroots in different ways, depending on the
> target.  Some of them I just went onto the target system and created a
> tar file containing the stuff I needed for the sysroot (I have a script
> that does this).  Others I extract the upstream packages (RPM or DPKG)
> directly into a separate sysroot area.
>
> In any event, I would find it very annoying if GCC copied important
> internal files/libraries into the sysroot.  I want my sysroots to be
> read-only and unmodified from the target, and the toolsuite libraries to
> be contained within the toolsuite environment.  Cross-pollination
> between those would be extremely frustrating for me.
>
> If you did want to preserve this ability I would recommend doing it the
> other way: use the standard installation environment by default and
> offer a script that could be invoked to copy the toolsuite libraries
> into the sysroot.  Not only would that give you a better idea of whether
> the extra step was necessary (people would know if they needed it,
> because they'd have to run the extra script), it would also allow
> sysroots to be updated "on the fly" instead of having them preinstalled.
>
>
> Personally I've not run across any packages which did not build properly
> unless the compiler libraries existed in the sysroot.  They've all
> worked fine for me.  However if there were packages that failed, in my
> opinion that would be an error in the upstream package and should be
> reported there and fixed.  They're obviously doing something incorrect
> in their build environments.


in the end libgcc and libstdc++ and other gcc runtime libs
go into target root file system under /lib or /usr/lib so
them there is a good thing otherwise gcc might link to local versions where
you are expecting it to use the one from your sysroot.
or you should construct your sysroot such that you expect these libraries to
be populated from cross toolchain.

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

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