external toolchain question
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
Signature · 5 lines
------------------------------------------------------------------------ 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 ------------------------------------------------------------------------
Am 15.09.2010 20:17, schrieb William Wagner:
Quoted 13 lines
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.
Quoted 4 lines
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
Marcus, All,
Quoted 2 lines · 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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
Am 15.09.2010 20:50, schrieb Yann E. MORIN:
Quoted 9 lines
Marcus, All,
Quoted 2 lines · 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
Marcus, All,
Quoted 1 line · 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! :-)
Quoted 4 lines
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
Quoted 2 lines
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...
Quoted 2 lines
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. :-)
Quoted 2 lines
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.
Quoted 5 lines
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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
Quoted 4 lines · On Wed, 15 Sep 2010 19:17:03 +0100 William Wagner <[email protected]>…
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 ?
Quoted 2 lines
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.
Quoted 1 line
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 11 lines · Thomas Petazzoni
Quoted 4 lines · On Wed, 15 Sep 2010 19:17:03 +0100 William Wagner<[email protected]>…
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.
Quoted 6 lines
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/orusr/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.
Signature · 5 lines
------------------------------------------------------------------------ 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 ------------------------------------------------------------------------
Quoted 3 lines · On Thu, 16 Sep 2010 09:03:11 +0100 William Wagner <[email protected]>…
With libstdc++ in
/usr/libon 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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 16 lines · Thomas Petazzoni
Quoted 3 lines · On Thu, 16 Sep 2010 09:03:11 +0100 William Wagner<[email protected]>…
With libstdc++ in
/usr/libon 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 byecb7642cce36bc68d93f0eee677adc7da538228d.
Quoted 9 lines
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 in3c77bab2eeace3ee675bd745ca335fa3dd1630bb. The result is that libstdc++ is back into a usual location in Buildroot toolchains, so we could in fact more or less revertecb7642cce36bc68d93f0eee677adc7da538228dand 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.
Quoted 3 lines
Thanks for the report!
Thomas
Signature · 5 lines
------------------------------------------------------------------------ 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 ------------------------------------------------------------------------
Quoted 3 lines · On Thu, 16 Sep 2010 12:41:09 +0100 William Wagner <[email protected]>…
We could change
copy_toolchain_lib_rootso 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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com