Re: GCC support libraries and sysroot

[Michael Hope <michael.hope@linaro.org>]

On 26 March 2012 07:27, Khem Raj <raj.khem@gmail.com> wrote:
> 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.

Part of this is due to our abuse of crosstool.  You normally build a
compiler plus a sysroot but we're building a compiler against a
sysroot.  In the normal configuration you'd then copy the sysroot to
the device and want the GCC runtime to come with the copy.  In ours
the device is already set up including a compatible (but not
identical) runtime.

Interesting.  I'll patch this in our branch and send a copy to the
list as a FYI.

-- Michael

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