GCC support libraries and sysroot

[Paul Smith]

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.

Cheers!


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