[Buildroot] external toolchain question

[Buildroot] external toolchain question

[William Wagner]

  Hello,

I'm trying to get a crosstool-ng toolchain working and running into a 
few problems. One thing I found with c++ support was that libstdc++ was 
being copied into target/usr/lib but it was located in staging/lib.

It seems like this commit 
http://git.buildroot.net/buildroot/commit/?id=ecb7642cce36bc68d93f0eee677adc7da538228d 
explicitly moved it in the target. The comment appears to be for an 
external buildroot toolchain not a crosstools toochain. Is that why it 
works for some people? For my crosstools toolchain it seemed that moving 
it fixed my problem.

As an aside what is the status of using a buildroot generated toolchain 
as an external toolchain? Any instructions anywhere on how to do it?

Thanks
Will

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] external toolchain question

[Marcus Osdoba]

  Am 15.09.2010 20:17, schrieb William Wagner:
>  Hello,
>
> I'm trying to get a crosstool-ng toolchain working and running into a 
> few problems. One thing I found with c++ support was that libstdc++ 
> was being copied into target/usr/lib but it was located in staging/lib.
>
> It seems like this commit 
> http://git.buildroot.net/buildroot/commit/?id=ecb7642cce36bc68d93f0eee677adc7da538228d 
> explicitly moved it in the target. The comment appears to be for an 
> external buildroot toolchain not a crosstools toochain. Is that why it 
> works for some people? For my crosstools toolchain it seemed that 
> moving it fixed my problem.
>
> As an aside what is the status of using a buildroot generated 
> toolchain as an external toolchain? Any instructions anywhere on how 
> to do it?
>
Hi Will,
I asked a similar questions some time before. Grant answered to my 
question "preserve toolchain", that he didn't manage to recycle the 
buildroot generated toolchain for a second run in an easy way. So it 
seems, that you are forced to from scratch including the toolchain if 
you do not use a "complete" external toolchain (e.g. generated with 
crosstool-ng).

Personally I didn't yet try out crosstool-ng because the current 
patchlevel of buildroot is a higher one (e.g. gcc 4.3.4 vs 4.3.5).

Regards,
Marcus

[Buildroot] external toolchain question

[Yann E. MORIN]

Marcus, All,

On Wednesday 15 September 2010 20:40:54 Marcus Osdoba wrote:
> Personally I didn't yet try out crosstool-ng because the current 
> patchlevel of buildroot is a higher one (e.g. gcc 4.3.4 vs 4.3.5).

Hmmm... crosstool-NG has gcc-4.4.3, and even 4.4.4 and 4.5.x in
experimental status.

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

[Buildroot] external toolchain question

[Marcus Osdoba]

  Am 15.09.2010 20:50, schrieb Yann E. MORIN:
> Marcus, All,
>
> On Wednesday 15 September 2010 20:40:54 Marcus Osdoba wrote:
>> Personally I didn't yet try out crosstool-ng because the current
>> patchlevel of buildroot is a higher one (e.g. gcc 4.3.4 vs 4.3.5).
> Hmmm... crosstool-NG has gcc-4.4.3, and even 4.4.4 and 4.5.x in
> experimental status.
>
>
Sorry, I didn't want to dispraise your work. Crosstool-ng is amazing!

But I had a quick look into it and figured out:
BR has 4.3.5 since June 2010 and 4.4.4 since May 2010.
The crosstool-ng version 1.8.1 provides 4.3.4 and 4.4.3 as default. With 
experimental activated no 4.3.5 either.
The eglibc points to 2.10 (2.11stable/2.12exp) and glibc to 2.9 
(2.11.2stable/2.12exp).
So my overall (subjective) impression was that br has currently a higher 
patchlevel.


By the way, I completely agree with Peters opinion that crosstool-ng 
could provide "better" toolchains while br focusses on it's maintask. 
Crosstool-ng is designed to generate toolchains as a specialised tool - 
really great. I saw that integration of ct-ng in br (or more intuitive 
config wrapper) is quite a long time on the agenda. I think it would be 
very eligible to see it in br.
What is the current status of this idea?

Thanks for your great work.

Regards,
Marcus

[Buildroot] external toolchain question

[Yann E. MORIN]

Marcus, All,

On Wednesday 15 September 2010 21:33:08 Marcus Osdoba wrote:
> Sorry, I didn't want to dispraise your work. Crosstool-ng is amazing!

No problem, I did take no offense! :-)

> But I had a quick look into it and figured out:
> BR has 4.3.5 since June 2010 and 4.4.4 since May 2010.
> The crosstool-ng version 1.8.1 provides 4.3.4 and 4.4.3 as default. With 
> experimental activated no 4.3.5 either.

Well, I focus on adding the latest versions, and easily give up on legacy
stuff. The way forward is not 4.3, but 4.5. But, if you find 4.3.x is
still usefull to you, then you can submit support for that and it'll make
in! :-)

And since you speak of dates...  ;-)
- gcc-4.4.4 is in since May the 16th, 2010
- gcc-4.5.0 is in since April the 15th, 2010
- gcc-4.5.1 is in since August the 1st, 2010

> The eglibc points to 2.10 (2.11stable/2.12exp) and glibc to 2.9 
> (2.11.2stable/2.12exp).

Well, glibc is... Special, to say the least. I'm not using it very often,
so it lags behind...

> So my overall (subjective) impression was that br has currently a higher 
> patchlevel.

Not "patchlevel". I'd rather say "more and/or newer features". The fact
is, the default in crosstool-NG is gcc-4.4.3, and gcc-4.4.4 in buildroot.
That's not a big gap, and being closed shortly I hope. ;-)

But if you look closely, crosstool-NG has support for Linux, Mingw32, and
bare-metal. It has support for glibc, eglibc, uClibc, newlib. It is fairly
easy to add new alternatives to any component.

Toolchain-wise, buildroot has support for Linux and uClibc; that's inherent
to its history.
But it is also capable of building a whole lot of userland packages.

Not the same goal, not the same feature set. :-)

> By the way, I completely agree with Peters opinion that crosstool-ng 
> could provide "better" toolchains while br focusses on it's maintask.

Yes, this is the ultimate, loooong term goal.

> Crosstool-ng is designed to generate toolchains as a specialised tool - 
> really great. I saw that integration of ct-ng in br (or more intuitive 
> config wrapper) is quite a long time on the agenda. I think it would be 
> very eligible to see it in br.
> What is the current status of this idea?

That's a legitimate question. I'll post a summary on the list shortly.
Thanks for asking! :-)

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

[Buildroot] external toolchain question

[Thomas Petazzoni]

On Wed, 15 Sep 2010 19:17:03 +0100
William Wagner <will_wagner@carallon.com> wrote:

> I'm trying to get a crosstool-ng toolchain working and running into a 
> few problems. One thing I found with c++ support was that libstdc++
> was being copied into target/usr/lib but it was located in
> staging/lib.

What's inside staging/ is just a bare copy of the toolchain sysroot. As
the toolchain sysroot organization depends on the toolchain, libstdc++
might be located in lib/ or usr/lib in staging.

For the target, I thought that it'd be a good idea to have it under
usr/lib regardless of whether it was in lib/ or usr/lib/ in the staging
directory. This is because "essential" applications do not usually
depend on libstdc++, so the natural location for libsdc++ is usr/lib.

Is it causing any sort of problem for you ?

> As an aside what is the status of using a buildroot generated
> toolchain as an external toolchain?

It should work, my testing environment includes :

 * CodeSourcery toolchains (ARM, PowerPC, MIPS, sh)
 * Buildroot external toolchains (x86, ARM, AVR32, mipsel,
   powerpc, sh)
 * Crosstool-NG external toolchains (ARM glibc, ARM uclibc, i586
   uclibc, mips uclibc, powerpc uclibc)

All those toolchains work, at least in the cases I've tested, of course.

> Any instructions anywhere on how to do it?

 * Select architecture
 * In Build options, change the staging dir location to where you want
   the toolchain to be installed 
 * Disable the Busybox package
 * Disable the ext2 filesystem generation

That should be it.

Regards,

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

[Buildroot] external toolchain question

[William Wagner]

  On 15/09/2010 20:19, Thomas Petazzoni wrote:
> On Wed, 15 Sep 2010 19:17:03 +0100
> William Wagner<will_wagner@carallon.com>  wrote:
>
>> I'm trying to get a crosstool-ng toolchain working and running into a
>> few problems. One thing I found with c++ support was that libstdc++
>> was being copied into target/usr/lib but it was located in
>> staging/lib.
> What's inside staging/ is just a bare copy of the toolchain sysroot. As
> the toolchain sysroot organization depends on the toolchain, libstdc++
> might be located in lib/ or usr/lib in staging.
>
> For the target, I thought that it'd be a good idea to have it under
> usr/lib regardless of whether it was in lib/ or usr/lib/ in the staging
> directory. This is because "essential" applications do not usually
> depend on libstdc++, so the natural location for libsdc++ is usr/lib.
>
> Is it causing any sort of problem for you ?
With libstdc++ in /usr/lib on target but /lib in staging I was getting 
an error in gdb when it tried to load libstdc++, moving the library 
fixed the problem.

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] external toolchain question

[Thomas Petazzoni]

On Thu, 16 Sep 2010 09:03:11 +0100
William Wagner <will_wagner@carallon.com> wrote:

> With libstdc++ in /usr/lib on target but /lib in staging I was
> getting an error in gdb when it tried to load libstdc++, moving the
> library fixed the problem.

Hum, right, ok.

The old behaviour was to find each library in staging/ and then copy it
to the same location in target/. Unfortunately, it was causing problems
with Buildroot toolchains, because in those, libstdc++ was neither in
lib/ or in usr/lib, but in usr/<tuple>/lib. Therefore, I moved to a
strategy that consists in having a fixed destination for the library on
the target filesystem. This was implemented by
ecb7642cce36bc68d93f0eee677adc7da538228d.

However, later on, to fix other issues, also related to libstdc++, I
modified the build procedure for Buildroot toolchains so that a
<tuple>/lib -> lib/ is created, as other toolchain building systems are
doing. This was implemented in
3c77bab2eeace3ee675bd745ca335fa3dd1630bb. The result is that libstdc++
is back into a usual location in Buildroot toolchains, so we could in
fact more or less revert ecb7642cce36bc68d93f0eee677adc7da538228d and
make sure that libraries are at the same location in both staging/ and
target/. I'll cook a patch for this.

Thanks for the report!

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

[Buildroot] external toolchain question

[William Wagner]

  On 16/09/2010 10:04, Thomas Petazzoni wrote:
> On Thu, 16 Sep 2010 09:03:11 +0100
> William Wagner<will_wagner@carallon.com>  wrote:
>
>> With libstdc++ in /usr/lib on target but /lib in staging I was
>> getting an error in gdb when it tried to load libstdc++, moving the
>> library fixed the problem.
> Hum, right, ok.
>
> The old behaviour was to find each library in staging/ and then copy it
> to the same location in target/. Unfortunately, it was causing problems
> with Buildroot toolchains, because in those, libstdc++ was neither in
> lib/ or in usr/lib, but in usr/<tuple>/lib. Therefore, I moved to a
> strategy that consists in having a fixed destination for the library on
> the target filesystem. This was implemented by
> ecb7642cce36bc68d93f0eee677adc7da538228d.
>
> However, later on, to fix other issues, also related to libstdc++, I
> modified the build procedure for Buildroot toolchains so that a
> <tuple>/lib ->  lib/ is created, as other toolchain building systems are
> doing. This was implemented in
> 3c77bab2eeace3ee675bd745ca335fa3dd1630bb. The result is that libstdc++
> is back into a usual location in Buildroot toolchains, so we could in
> fact more or less revert ecb7642cce36bc68d93f0eee677adc7da538228d and
> make sure that libraries are at the same location in both staging/ and
> target/. I'll cook a patch for this.

Have now also tried a code sourcery toolchain which puts libstdc++ in 
/usr/lib and if they don't match again get the error.

We could change copy_toolchain_lib_root so that it puts the libraries in 
the corresponding location it finds them in rather than currently 
searching in three locations but always copying to the specified one.

> Thanks for the report!
>
> Thomas

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] external toolchain question

[Thomas Petazzoni]

On Thu, 16 Sep 2010 12:41:09 +0100
William Wagner <will_wagner@carallon.com> wrote:

> We could change copy_toolchain_lib_root so that it puts the libraries
> in the corresponding location it finds them in rather than currently 
> searching in three locations but always copying to the specified one.

Absolutely. That's what the code was doing prior to
ecb7642cce36bc68d93f0eee677adc7da538228d.

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