[Buildroot] external toolchain

[Buildroot] external toolchain

[Jonathan dumaresq]

Hi all,

Does any one here have used the crosstoll-ng for AVR32 with buildroot ?

Does it work correctly. From What I see, the crosstool is marked as
experimental and do not offer c++ support. 

Is it possible to use the toolchain build by buildroot and reusit as
external toolchain ?

Jonathan

[Buildroot] external toolchain

[Thomas Petazzoni]

Le Tue, 1 Dec 2009 08:59:46 -0500,
"Jonathan dumaresq" <jdumaresq@cimeq.qc.ca> a ?crit :

> Does any one here have used the crosstoll-ng for AVR32 with
> buildroot ?

The AVR32 support in Crosstool-NG is bare-meta only (based on newlib).
So such a toolchain cannot be used in Buildroot. You'd first have to
contribute to Crosstool-NG to add support for uClibc and/or glibc.

Sincerly,

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

[Buildroot] external toolchain

[Jonathan dumaresq]

Hi Thomas,

-----Message d'origine-----
De?: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] De
la part de Thomas Petazzoni
Envoy??: 1 d?cembre 2009 09:33
??: buildroot at busybox.net
Objet?: Re: [Buildroot] external toolchain

Le Tue, 1 Dec 2009 08:59:46 -0500,
"Jonathan dumaresq" <jdumaresq@cimeq.qc.ca> a ?crit :

> Does any one here have used the crosstoll-ng for AVR32 with
> buildroot ?

The AVR32 support in Crosstool-NG is bare-meta only (based on newlib).
So such a toolchain cannot be used in Buildroot. You'd first have to
contribute to Crosstool-NG to add support for uClibc and/or glibc.

This is what I though. 

Thanx for your help again, and save me some hours....

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
-- 

[Buildroot] external toolchain

[Peter Korsgaard]

>>>>> "Jonathan" == Jonathan dumaresq <jdumaresq@cimeq.qc.ca> writes:

 Jonathan> Hi all,
 Jonathan> Does any one here have used the crosstoll-ng for AVR32 with buildroot ?

Last I looked, crosstool-ng didn't support avr32-on-linux, only
barebone?

 Jonathan> Is it possible to use the toolchain build by buildroot and reusit as
 Jonathan> external toolchain ?

Yes, that should work OK.

-- 
Bye, Peter Korsgaard

[Buildroot] external toolchain

[Jonathan dumaresq]

Hi Peter,


-----Message d'origine-----
De?: Peter Korsgaard [mailto:jacmet at gmail.com] De la part de Peter Korsgaard
Envoy??: 1 d?cembre 2009 09:50
??: Jonathan dumaresq
Cc?: buildroot at busybox.net
Objet?: Re: [Buildroot] external toolchain

>>>>> "Jonathan" == Jonathan dumaresq <jdumaresq@cimeq.qc.ca> writes:

 Jonathan> Hi all,
 Jonathan> Does any one here have used the crosstoll-ng for AVR32 with
buildroot ?

Last I looked, crosstool-ng didn't support avr32-on-linux, only
barebone?

 Jonathan> Is it possible to use the toolchain build by buildroot and reusit
as
 Jonathan> external toolchain ?

Yes, that should work OK.

Good news. Is it possible to build only the toolchain ?

Jonathan

-- 
Bye, Peter Korsgaard

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Ce message entrant est certifi? sans virus connu.
Analyse effectu?e par AVG - www.avg.fr 
Version: 9.0.709 / Base de donn?es virale: 270.14.88/2538 - Date: 12/01/09
02:59:00

[Buildroot] external toolchain

[Peter Korsgaard]

>>>>> "Jonathan" == Jonathan dumaresq <jdumaresq@cimeq.qc.ca> writes:

Hi,

 Jonathan> Good news. Is it possible to build only the toolchain ?

Sure, just don't enable any packages / kernel / target file systems.

-- 
Bye, Peter Korsgaard

[Buildroot] external toolchain

[Jonathan dumaresq]

Hi Peter,

-----Message d'origine-----
De?: Peter Korsgaard [mailto:jacmet at gmail.com] De la part de Peter Korsgaard
Envoy??: 1 d?cembre 2009 09:50
??: Jonathan dumaresq
Cc?: buildroot at busybox.net
Objet?: Re: [Buildroot] external toolchain


 Jonathan> Is it possible to use the toolchain build by buildroot and reusit
as
 Jonathan> external toolchain ?

Yes, that should work OK.

I got this error when I try to use the external toolchain

Checking external toolchain settings
External toolchain doesn't support --sysroot. Cannot use.
exit 1
make: *** [/buildroot/buildroot/cth/stamps/ext-toolchain-installed] Error 1

I build the external from buildroot

Jonathan

-- 
Bye, Peter Korsgaard

[Buildroot] external toolchain

[Peter Korsgaard]

>>>>> "Jonathan" == Jonathan dumaresq <jdumaresq@cimeq.qc.ca> writes:

Hi,

 Jonathan> I got this error when I try to use the external toolchain

 Jonathan> Checking external toolchain settings
 Jonathan> External toolchain doesn't support --sysroot. Cannot use.

And did you enable sysroot support (BR2_TOOLCHAIN_SYSROOT)?

-- 
Bye, Peter Korsgaard

[Buildroot] external toolchain

[Jonathan dumaresq]

Hi Peter,

-----Message d'origine-----
De?: Peter Korsgaard [mailto:jacmet at gmail.com] De la part de Peter Korsgaard
Envoy??: 1 d?cembre 2009 15:32
??: Jonathan dumaresq
Cc?: 'Peter Korsgaard'; buildroot at busybox.net
Objet?: Re: [Buildroot] external toolchain

>>>>> "Jonathan" == Jonathan dumaresq <jdumaresq@cimeq.qc.ca> writes:

Hi,

 Jonathan> I got this error when I try to use the external toolchain

 Jonathan> Checking external toolchain settings
 Jonathan> External toolchain doesn't support --sysroot. Cannot use.

And did you enable sysroot support (BR2_TOOLCHAIN_SYSROOT)?


Arrrggghhh

I'll try it

Jonathan

-- 
Bye, Peter Korsgaard

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Ce message entrant est certifi? sans virus connu.
Analyse effectu?e par AVG - www.avg.fr 
Version: 9.0.709 / Base de donn?es virale: 270.14.88/2538 - Date: 12/01/09
02:59:00

[Buildroot] external toolchain

[Zoran Djordjevic]

Well, Yann, no matter if I suceed or no,?I must tell that 
your answer is just an example of clear and streightforward 
explanation. 
At my sorrow, it also?tells me that I am at the very, very, very 
beginning?of learning Linux internals. 
If I persist, I'll ask some more questions.
?
Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120819/022046fc/attachment.html>

[Buildroot] external toolchain

[Zoran Djordjevic]

Thank you?Yann for revealing me the matter about Crosstool- NG adjustment
and related to glibc. I?was not?able to try (but will do at monday), however,
it raises another question to me. Having in mind that I built with??2.6.9 choice?
- which is default (although I didn't know the fact) and that my exact kernel
version is 2.6.32.2 (that is on target board) then how it comes?the error
"kernel too old" (because target kernel is newer one) ???
?
Best regard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120818/28925e21/attachment.html>

[Buildroot] external toolchain

[Yann E. MORIN]

Zoran, All,

On Saturday 18 August 2012 09:33:42 Zoran Djordjevic wrote:
> Thank you Yann for revealing me the matter about Crosstool- NG adjustment
> and related to glibc. I was not able to try (but will do at monday), however,
> it raises another question to me. Having in mind that I built with  2.6.9 choice 
> - which is default (although I didn't know the fact)

No, 2.6.9 is *not* the default. The default (at least for crosstool-NG) is
to use the same version as is used by the kernel headers. Thus, if you used
kernel headers greater than 2.6.32 (say, 2.6.39), then the oldest kernel
supported at runtime by the C library will be 2.6.39.

If you want to support an older kernel than the one used for the kernel
headers, then you have to tell glibc about that fact.

> and that my exact kernel
> version is 2.6.32.2 (that is on target board) then how it comes the error
> "kernel too old" (because target kernel is newer one) ?  

Basically, that's how it works:
  - C library needs the kernel headers to know the kernel ABI/API.
  - thus, C library can make use of /advanced/ native kernel features, or
    emulate them
  - C library also needs to know what oldest kernel will be used at runtime,
    to provision (if possible) for missing features in older kernels.

For example, let's take AIO (Asynchronous Input/Output):
    kernel headers              : 3.5
    first kernel with native AIO: 2.6.37 [*]
    kernel on target            : 2.6.32

In this case, *by default*, the C library (glibc) will:
  - know that AIO are native in the headers, because it knows that AIO were
    introduced in 2.6.37, and that the headers are 3.5
  - so it will directly use native AIO
  - and will not emulate them

But if you tell glibc that it is expected to run on a kernel as old as 2.6.32,
then it will know that:
  - it can use native AIO by default (3.5 has AIO)
  - it should also provision emulated AIO in case they are missing at runtime

So you have three options when you build your toolchain:
  - use the kernel headers from the oldest kernel you'll be using on the
    target
  - use older kernel headers (not recommended)
  - use newer (or the newest) kernel headers, and specify the oldest kernel
    you'll be using.

Of course, if you'll only be using only one version on your target, and will
never, ever upgrade your kernel, option 1 is the best option. But, if you are
supposed/able to boot different kernel versions, then option 3 is the best,
because you can use native kernel features if they are present, and fallback
to emulation if they are missing. Option 2 is rarely an option.

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

[Zoran Djordjevic]

Hello
?
I am using buildroot to build RFS with external toolchain support.
When using?Crosstool- NG, it builds OK, but on my target I got
an error- saying "kernel too old". Seems to me that there is no other
way out (is it so ?) knowing that 2.6.32 is the?latest?kernel that I 
found for my board.?So I tried with Sourcery Code Bench ARM2009q1. 
While building, it shows an error, regarding libev - saying:
"memory fences not defined for your architecture, please report".
I don't know the meaning and apparently how to avoid that (if
possible), so I ask myself can I?miss?building libev (or better how
can I solve above mentined issue) ?? In fact I can avoid it, by simple
uncheking appropriate check box, ?but what consequences?can be then ?
?
Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120817/7171a513/attachment.html>

[Buildroot] external toolchain

[Yann E. MORIN]

Zoran, All,

On Friday 17 August 2012 14:47:09 Zoran Djordjevic wrote:
> I am using buildroot to build RFS with external toolchain support.
> When using Crosstool- NG, it builds OK, but on my target I got
> an error- saying "kernel too old".

When you build your toolchain with crosstool-NG, you can tell glibc what the
oldest supported kernel should be:
    C-library  --->
        Minimum supported kernel version (Specific kernel version)  --->
            (2.6.9) Minimum kernel version to support

Of course, 2.6.9 is just an example. Use whatever you see fit for your
use-case (eg. 2.6.32?)

> Seems to me that there is no other
> way out (is it so ?) knowing that 2.6.32 is the latest kernel that I 
> found for my board.

Bug your provider about this issue. Tell them they should upgrade. ;-)

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

[Zoran Djordjevic]

Thank you for revealing me the matter about Crosstool- NG adjustment
and related to glibc. I?was not?able to try (but will do at monday), however,
it raises another question to me. Having in mind that I built with??2.6.9 choice?
- which is default (although I didn't know the fact) and that my exact kernel
version is 2.6.32.2 (that is on target board) then how it comes error
"kernel too old" (because target kernel is newer one) ???
?
Best regards
?


________________________________
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot at busybox.net; Zoran Djordjevic <djdjdjole@yahoo.com> 
Sent: Friday, August 17, 2012 3:19 PM
Subject: Re: [Buildroot] external toolchain

Zoran, All,

On Friday 17 August 2012 14:47:09 Zoran Djordjevic wrote:
> I am using buildroot to build RFS with external toolchain support.
> When using Crosstool- NG, it builds OK, but on my target I got
> an error- saying "kernel too old".

When you build your toolchain with crosstool-NG, you can tell glibc what the
oldest supported kernel should be:
? ? C-library? --->
? ? ? ? Minimum supported kernel version (Specific kernel version)? --->
? ? ? ? ? ? (2.6.9) Minimum kernel version to support

Of course, 2.6.9 is just an example. Use whatever you see fit for your
use-case (eg. 2.6.32?)

> Seems to me that there is no other
> way out (is it so ?) knowing that 2.6.32 is the latest kernel that I 
> found for my board.

Bug your provider about this issue. Tell them they should upgrade. ;-)

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.? |
'------------------------------^-------^------------------^--------------------'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120817/7614f7e6/attachment.html>

[Buildroot] External Toolchain

[Charles Krinke]

I'm trying to understand the use of an external toolchain in buildroot.

I have the latest CodeSourcery toolchain. This is the one from
http://www.codesourcery.com/sgpp/lite/power/portal/release1571 which is gcc
4.5.1.

I am trying to integrate it into buildroot sufficiently to build just root
filesystems for my project.

I have it in my path and it is "powerpc-linux-gnu-" and installed it in its
default location which is "/root/CodeSourcery/Sourcery_G++_Lite/bin/".

Next, I changed External Toolchain path from "/path/to/staging_dir/usr" to
"/root/CodeSourcery/Sourcery_G++_Lite/" and "External toolchain prefix from
"$(ARCH)-linux" to "powerpc-linux-gnu" and when running a make with the
uclibc option selected I get "Checking external toolchain settings,
Incorrect selection of the C library". When I select "glibc" instead, I just
get an "Error 1" from make and no additional information.

I would like to use a CodeSourcery binary and I would like to compile both
glibc and uclibc root filesystems.

Could I ask for a little help understanding what is going on, please?

-- 
Charles Krinke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110409/f49f3d19/attachment.html>

[Buildroot] External toolchain

[H Hartley Sweeten]

Hello all,

This might not be the correct list to ask this on but I'll try anyway..

I have been using Buildroot with an external toolchain provided by
Cirrus Logic for an ARM ep93xx based board. This toolchain has worked
fine ever since I started using it.

$ arm-linux-gcc --version
arm-linux-gcc (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

I just grabbed the latest 2.6.29 kernel and it appears the 4.1.1
compiler is not compatible, this is in include/linux/compiler-gcc4.h:

/* GCC 4.1.[01] miscompiles __weak */
#if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
# error Your version of gcc miscompiles the __weak directive
#endif

Ok.. Fine... I needed/wanted to switch to a newer toolchain for
sometime. On recommendation from another ep93xx user I downloaded the
Code Sourcery G++ 207q3-51 toolchain.

$ arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (CodeSourcery Sourcery G++ Lite 2007q3-51)
4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Now I have a problem I can't figure out.

I can get Buildroot to use the Code Sourcery toolchain and it compiles
the 2.6.29 kernel fine. But, when I try to boot the kernel it just hangs
after the "Uncompressing Linux.... done, booting the kernel." step.

I went back to kernel 2.6.28.8 and tried it with the Code Sourcery
toolchain, same results. But, if I switch back to the Cirrus 4.1.1
toolchain the kernel boots fine.

Am I just missing something? Any help would be appreciated.

Thanks,
Hartley

[Buildroot] External toolchain

[Daniel Mack]

On Wed, Mar 25, 2009 at 06:14:05PM -0400, H Hartley Sweeten wrote:
> This might not be the correct list to ask this on but I'll try anyway..
> 
> I have been using Buildroot with an external toolchain provided by
> Cirrus Logic for an ARM ep93xx based board. This toolchain has worked
> fine ever since I started using it.

Just curious - why don't you let buildroot build the toolchain for you?

[...]

> Now I have a problem I can't figure out.
> 
> I can get Buildroot to use the Code Sourcery toolchain and it compiles
> the 2.6.29 kernel fine. But, when I try to boot the kernel it just hangs
> after the "Uncompressing Linux.... done, booting the kernel." step.
> 
> I went back to kernel 2.6.28.8 and tried it with the Code Sourcery
> toolchain, same results. But, if I switch back to the Cirrus 4.1.1
> toolchain the kernel boots fine.

We had similar problems discussed on that list just recently. Not sure
whether you're facing exactly the same thing here, but it might be a
pointer.

The problem on other ARM based boards was configurations of gcc using
cpu-specific extensions by default which makes the kernel build system
used them to build the kernel - which eventually results in unbootable
images.

See this thread:

  http://lists.busybox.net/pipermail/buildroot/2009-March/026580.html

Hope that helps :) And if it does, it might be worth including some
proven to work configs in the buildroot repository.

Daniel

[Buildroot] External toolchain

[H Hartley Sweeten]

On Wednesday, March 25, 2009 4:36 PM, Daniel Mack wrote:
> On Wed, Mar 25, 2009 at 06:14:05PM -0400, H Hartley Sweeten wrote:
> > This might not be the correct list to ask this on but I'll try
> > anyway..
> > 
> > I have been using Buildroot with an external toolchain provided
> > by Cirrus Logic for an ARM ep93xx based board. This toolchain has
> > worked fine ever since I started using it.
> 
> Just curious - why don't you let buildroot build the toolchain for
> you?

I tried that once before and just ended up with a big mess.

That's one of the pieces of Buildroot that I really don't get.. :-(

[...]

> > Now I have a problem I can't figure out.
> > 
> > I can get Buildroot to use the Code Sourcery toolchain and it
> > compiles the 2.6.29 kernel fine. But, when I try to boot the
> > kernel it just hangs after the "Uncompressing Linux.... done,
> > booting the kernel." step.
> >  
> > I went back to kernel 2.6.28.8 and tried it with the Code
> > Sourcery toolchain, same results. But, if I switch back to the
> > Cirrus 4.1.1 toolchain the kernel boots fine.
> 
> We had similar problems discussed on that list just recently. Not
> sure whether you're facing exactly the same thing here, but it might
> be a pointer.

I'll look at the thread and see if anything help.

> The problem on other ARM based boards was configurations of gcc
> using cpu-specific extensions by default which makes the kernel
> build system used them to build the kernel - which eventually
> results in unbootable images.

The strange thing is, the Code Sourcery toolchain works fine with the
other ep93xx user. I'm hoping I just have something messed up.

Also, I would assume if the toolchain had some default cpu-specific
extensions then the "Uncompressing Linux... " wouldn't even work.
But, again I don't know...

> See this thread:
> 
>   http://lists.busybox.net/pipermail/buildroot/2009-March/026580.html
> 
> Hope that helps :) And if it does, it might be worth including some
> proven to work configs in the buildroot repository.

I'll look it over. Maybe it will help.

Thanks,
Hartley