GCC support libraries and sysroot

GCC support libraries and sysroot

[Michael Hope]

Hi there.  Why does crosstool-NG create a symlink from
$tuple/$sysroot/lib to $tuple/lib?  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.

For our binary builds we plan to supply a few different sysroots
including a minimal libc, developer image with GTK and X, and a
desktop image with a wide range of packages.  They'll come as tarballs
and the intent is for people to delete the old $tuple/$sysroot and
extract the new one in its place.  Currently this means that the
support libraries will also get deleted.  The target comes with these
libraries preinstalled.

-- Michael

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

Building armv7 "cross-native" GCC

[Douglas Jerome]

Sorry if this is off-topic...

I have an armv7 cross-toool chain, which I made and it seems to
be OK as I use it to cross-build a small armv7 Linux distribution.

Now I am trying to use it to cross-build GCC itself so as to have
a native GCC in the arm Linux system I make.

I am using gcc-4.4.6, gmp-4.3.2 and mpfr-2.4.2 in both the
cross-tool chain and for the cross-native build.

For the cross-native build I copy the gmp and mpfr directories
into the gcc directory and cross-build; this works for similar
PowerPC, i686 and x86_64 cross-built systems. But for the armv7 I
get an undefined reference to `__gmpn_invert_limb' in divrem_1.c

I'm looking through the gmp source code... great fun, but I'm
not yet finding what is going wrong.

Does anyone have some experience with this and have a good
suggestion or two?

-- 
Douglas Jerome


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

Re: GCC support libraries and sysroot

[Yann E. MORIN]

Michael, All,

On Friday 23 March 2012 02:22:55 Michael Hope wrote:
> Hi there.  Why does crosstool-NG create a symlink from
> $tuple/$sysroot/lib to $tuple/lib?

Well... It does, yes. As for the exact reason, I'm not sure anymore...

First, the idea (in my convoluted brain) is that all target libraries
should be in the sysroot. After all, why would these libraries *not* be
in the sysroot? (I'm just questionning why gcc does not install these
libs there in the first place).

Second, there was no provision from the beginning for changing the sysroot
at all.

Third, crosstool-NG provides a script that ease populating the rootfs with
the libraries from the toolchain. For this, the script scans the rootfs for
missing libraries, and searches these libs in the sysroot. When found, it
copies the libraries to the rootfs, into the same relative path as they
were found in the sysroot.

Also, I seem to remember that in some conditions, the linker was not able
to find those "support libraries", unless they were present in the sysroot,
hence the symlink to be sure gcc would install those libs in a place the
linker would find them. It was a long time ago, so I'm not sure it still
applies now, or it was fixed as a side effect of another change...

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

I do agree that this is not the "standard" layout that people would expect.
Those symlinks could eventually go away, but I'd like to understand the
reason for this layout first. After all, in the "crosstool-NG land", the
current layout works OK. ;-)

> For our binary builds we plan to supply a few different sysroots
> including a minimal libc, developer image with GTK and X, and a
> desktop image with a wide range of packages.  They'll come as tarballs
> and the intent is for people to delete the old $tuple/$sysroot and
> extract the new one in its place.  Currently this means that the
> support libraries will also get deleted.

Unless they are also present in your customised "sysroot".

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

Re: 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

Re: GCC support libraries and sysroot

[Khem Raj]

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

Re: GCC support libraries and sysroot

[Michael Hope]

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

Re: GCC support libraries and sysroot

[Thomas Petazzoni]

Hello Michael,

Le Fri, 23 Mar 2012 14:22:55 +1300,
Michael Hope <michael.hope@linaro.org> a écrit :

> Hi there.  Why does crosstool-NG create a symlink from
> $tuple/$sysroot/lib to $tuple/lib?  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.

On the other hand, this was making things simple and easy for tools
like Buildroot to leverage the pre-built Linaro toolchains. The Linaro,
Sourcery CodeBench, Crosstool-NG and Buildroot toolchains all behaved
the same by installing all the libraries into the sysroot, so it was
easy to support all of them: we just copy the complete sysroot into a
"staging" directory, into which we add more libraries/headers as we
build stuff for the target.

Since Linaro 2012.03 (and therefore 2012.04), this simple idea doesn't
work anymore as Linaro toolchains have important stuff installed
outside of the sysroot, which makes it a lot more complicated for
Buildroot to handle (and I guess possibly other similar tools).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

Re: GCC support libraries and sysroot

[Michael Hope]

On 7 May 2012 04:36, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello Michael,
>
> Le Fri, 23 Mar 2012 14:22:55 +1300,
> Michael Hope <michael.hope@linaro.org> a écrit :
>
>> Hi there.  Why does crosstool-NG create a symlink from
>> $tuple/$sysroot/lib to $tuple/lib?  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.
>
> On the other hand, this was making things simple and easy for tools
> like Buildroot to leverage the pre-built Linaro toolchains. The Linaro,
> Sourcery CodeBench, Crosstool-NG and Buildroot toolchains all behaved
> the same by installing all the libraries into the sysroot, so it was
> easy to support all of them: we just copy the complete sysroot into a
> "staging" directory, into which we add more libraries/headers as we
> build stuff for the target.
>
> Since Linaro 2012.03 (and therefore 2012.04), this simple idea doesn't
> work anymore as Linaro toolchains have important stuff installed
> outside of the sysroot, which makes it a lot more complicated for
> Buildroot to handle (and I guess possibly other similar tools).

Hi Thomas.  CodeSourcery and crosstool-NG supply a compiler, runtime,
and sysroot.  We supply a compiler and runtime that work with a few
sysroots, and include a basic sysroot so the compiler works out of the
box.  It's important to me that an end user can easily swap out the
sysroot for a bigger or compatible (Fedora?  Debian?) one

Could you tell me more about your use case?  Perhaps we can tweak the
default sysroot.

-- Michael

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

Re: GCC support libraries and sysroot

[Thomas Petazzoni]

Le Mon, 7 May 2012 08:23:59 +1200,
Michael Hope <michael.hope@linaro.org> a écrit :

> Hi Thomas.  CodeSourcery and crosstool-NG supply a compiler, runtime,
> and sysroot.  We supply a compiler and runtime that work with a few
> sysroots, and include a basic sysroot so the compiler works out of the
> box.  It's important to me that an end user can easily swap out the
> sysroot for a bigger or compatible (Fedora?  Debian?) one
> 
> Could you tell me more about your use case?  Perhaps we can tweak the
> default sysroot.

Well, in the end, I managed to get things working for Buildroot. I
considered that the GCC support libraries (libgcc_s, libstdc++, etc.)
can be in a separate directory, outside the sysroot, and I tweaked our
external toolchain logic to support this case. It seems to work fine.

I'm not sure it's really readable, but the change I've done to
Buildroot is
http://git.buildroot.net/buildroot/commit/?id=e1f0804cc11706648f33a96d68e613b8d6593db3.
I've also added support for Linaro 2012.04, and I've successfully
generated and booted an ARM Linux system with Buildroot and the Linaro
2012.04 toolchain.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

Re: GCC support libraries and sysroot

[Maurizio Vitale]

Michael Hope <michael.hope <at> linaro.org> writes:

> 
> Hi there.  Why does crosstool-NG create a symlink from
> $tuple/$sysroot/lib to $tuple/lib?  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.
> 
> For our binary builds we plan to supply a few different sysroots
> including a minimal libc, developer image with GTK and X, and a
> desktop image with a wide range of packages.  They'll come as tarballs
> and the intent is for people to delete the old $tuple/$sysroot and
> extract the new one in its place.  Currently this means that the
> support libraries will also get deleted.  The target comes with these
> libraries preinstalled.
> 

I'm exploring similar sysroot setups (but in my case I want the sysroot to work 
for both gcc and clang). Other than size, what would go wrong with having all 
sysroots including the GCC's support libraries and whatever additional library 
the specific sysroot introduces?
Obviously it would require redistribution of all sysroot tarfiles whenever the 
compiler toolchain changes, but other than that and size, I don't see problems.
I've just started with this setup, so I might be missing the obvious.

  Maurizio


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

Re: GCC support libraries and sysroot

[Michael Hope]

On 16 July 2012 04:40, Maurizio Vitale <mrz.vtl@gmail.com> wrote:
> Michael Hope <michael.hope <at> linaro.org> writes:
>
>>
>> Hi there.  Why does crosstool-NG create a symlink from
>> $tuple/$sysroot/lib to $tuple/lib?  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.
>>
>> For our binary builds we plan to supply a few different sysroots
>> including a minimal libc, developer image with GTK and X, and a
>> desktop image with a wide range of packages.  They'll come as tarballs
>> and the intent is for people to delete the old $tuple/$sysroot and
>> extract the new one in its place.  Currently this means that the
>> support libraries will also get deleted.  The target comes with these
>> libraries preinstalled.
>>
>
> I'm exploring similar sysroot setups (but in my case I want the sysroot to work
> for both gcc and clang). Other than size, what would go wrong with having all
> sysroots including the GCC's support libraries and whatever additional library
> the specific sysroot introduces?
> Obviously it would require redistribution of all sysroot tarfiles whenever the
> compiler toolchain changes, but other than that and size, I don't see problems.
> I've just started with this setup, so I might be missing the obvious.

Hi Maurizio.  We release monthly so the cost would be unfortunate.

-- Michael

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