[Buildroot] Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15

[Buildroot] Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15

[MARCEL JANSSEN]

An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110926/e7fe2885/attachment.html>

[Buildroot] Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15

[Thomas Petazzoni]

Hello Marcel,

Le Mon, 26 Sep 2011 16:55:09 +0200,
"MARCEL JANSSEN" <korgull@home.nl> a ?crit :

> Thanks for your comment. I indeed still use OABI, but I have no
> reason to stay with that. So, to make things easier I will switch to
> EABI and see what will happen. It compiles well, I just need to check
> it on a real device, which probably is not issue as well. That
> doesn't mean that I'm not interested in a reply to my initial
> question regarding the invalid ABI and why fedora 15 triggers this
> error and fedora 14 does not. I guess some people will be looking for
> the same answer on the net, so if anyone knows what's the real cause
> it is still interesting to mention it I think.

I have no idea why OABI breaks on Fedora 15 and I'm personally not
really interested in fixing this, as support for OABI really isn't a
priority. Of course, interested parties are welcome to investigate the
problem and provide the corresponding fixes.

> Maybe its' nice to add "deprecated" to OABI ?
> Or perhaps, not even allow it any more if there's no real reason to
> chose it.

It might be needed for people having legacy binaries.

> I also decided to switch to the new buildroot immediately. It's so
> much better than the old one I was using and really appreciate all
> the efforts of the team. The time to port from my old buildroot to
> the new one took about 1 day and so far things seem to be ok. So far
> I'm very impressed by the new buildroot and I'm sure I will use it a
> lot ( and contribute as well when I can).

Thanks! Buildroot has indeed improved quite a lot during the last 2/3
years.

> I just have one question which probably belongs in the faq (I may
> have missed something as well). I can't yet figure out how to build
> the output for different devices without recompiling the whole
> toolchain. I have several different images which are just a little
> different in the sense that they all have the same kernel but some
> different packages. It would be great if I could just switch between
> configs and don't have to recompile the whole toolchain again or even
> shared packages between those configs.

Buildroot is very simple: one configuration, one build. No way to share
things across different builds. Adding the ability of sharing build
results across various builds complicates things a lot, and Buildroot
would lose one of its core advantage: simplicity.

Since the toolchain build typically accounts for a large part of the
overall build time, what we generally recommend in this kind of
situation is to make use of the external toolchain mechanism. The
principle is :

 1/ Generate a toolchain with Crosstool-NG, Buildroot or use a
    pre-compiled toolchain such as CodeSourcery ones.

 2/ Tell Buildroot to use this toolchain as an external toolchain.
    Buildroot will "import" this toolchain in just a few seconds, will
    skip the toolchain building process and start right away with the
    build process of the packages.

That's the mechanism I use for all my Buildroot-based projects. I
almost never use the internal Buildroot mechanism to build a toolchain.

Best regards,

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

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Arnout Vandecappelle]

On Monday 26 September 2011 16:55:09, MARCEL JANSSEN wrote:
> I just have one question which probably belongs in the faq (I may have
> missed something as well). I can't yet figure out how to build the output
> for different devices without recompiling the whole toolchain. I have
> several different images which are just a little different in the sense
> that they all have the same kernel but some different packages. It would
> be great if I could just switch between configs and don't have to
> recompile the whole toolchain again or even shared packages between those
> configs.

 Buildroot supports an external toolchain, but it isn't easy to create one.  
The easiest is to use a crosstool-NG toolchain: build it, install it in some 
central place, and use it as an external toolchain from buildroot.

 It would be nice if buildroot also supported creation of an external 
toolchain (based on an internal toolchain config).  The toolchain is currently 
built in output/host/usr/... and is not relocatable, so it's difficult to 
share it between different buildroot builds.

 Regards,
 ARnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110928/7a66a3c7/attachment-0001.html>

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Thomas De Schampheleire]

Hi,

On Wed, Sep 28, 2011 at 8:05 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
> On Monday 26 September 2011 16:55:09, MARCEL JANSSEN wrote:
>
>> I just have one question which probably belongs in the faq (I may have
>
>> missed something as well). I can't yet figure out how to build the output
>
>> for different devices without recompiling the whole toolchain. I have
>
>> several different images which are just a little different in the sense
>
>> that they all have the same kernel but some different packages. It would
>
>> be great if I could just switch between configs and don't have to
>
>> recompile the whole toolchain again or even shared packages between those
>
>> configs.
>
> Buildroot supports an external toolchain, but it isn't easy to create one.
> The easiest is to use a crosstool-NG toolchain: build it, install it in some
> central place, and use it as an external toolchain from buildroot.
>
> It would be nice if buildroot also supported creation of an external
> toolchain (based on an internal toolchain config). The toolchain is
> currently built in output/host/usr/... and is not relocatable, so it's
> difficult to share it between different buildroot builds.

The non-relocatability of the buildroot toolchain is a problem I am
experiencing as well. Specifying LD_LIBRARY_PATH works as a
workaround, but is not a proper solution. The issue was addressed in
following mail thread:
http://lists.busybox.net/pipermail/buildroot/2011-September/045407.html

Best regards,
Thomas

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Steve Calfee]

On 09/27/11 23:05, Arnout Vandecappelle wrote:
> 
> On Monday 26 September 2011 16:55:09, MARCEL JANSSEN wrote:
>> I just have one question which probably belongs in the faq (I may have
>> missed something as well). I can't yet figure out how to build the output
>> for different devices without recompiling the whole toolchain. I have
>> several different images which are just a little different in the sense
>> that they all have the same kernel but some different packages. It would
>> be great if I could just switch between configs and don't have to
>> recompile the whole toolchain again or even shared packages between those
>> configs.
> 
>  Buildroot supports an external toolchain, but it isn't easy to create one.  
> The easiest is to use a crosstool-NG toolchain: build it, install it in some 
> central place, and use it as an external toolchain from buildroot.
> 
>  It would be nice if buildroot also supported creation of an external 
> toolchain (based on an internal toolchain config).  The toolchain is currently 
> built in output/host/usr/... and is not relocatable, so it's difficult to 
> share it between different buildroot builds.
> 
HI Arnout,

I use the internal buildroot toolchain as an external toolchain all the
time. I first checkout the buildroot tree into the ....tools directory.
I select some defaultconfig, then do a make menuconfig and remove
everything but the toolchain building. The make then trundles for a long
time and finally I get a toolchain. I can easily change toolchain
options, if the target system needs something not in the default.

Then I checkout another buildroot tree into a working directory, and use
the make defaultconfig. Then I make menuconfig and set it up using the
newly created tools tree toolchain as an external toolchain. This speeds
up the builds in the working directory, and I don't have to worry about
the dreaded "make clean" problem of wiping the tools.

More than one working buildroot configuration can use the same tools, as
long as the same tool options are used in all "parallel" working trees.

Regards, Steve

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Thomas De Schampheleire]

Hi Steve,

On Wed, Sep 28, 2011 at 8:30 PM, Steve Calfee <stevecalfee@gmail.com> wrote:
> On 09/27/11 23:05, Arnout Vandecappelle wrote:
>>
>> On Monday 26 September 2011 16:55:09, MARCEL JANSSEN wrote:
>>> I just have one question which probably belongs in the faq (I may have
>>> missed something as well). I can't yet figure out how to build the output
>>> for different devices without recompiling the whole toolchain. I have
>>> several different images which are just a little different in the sense
>>> that they all have the same kernel but some different packages. It would
>>> be great if I could just switch between configs and don't have to
>>> recompile the whole toolchain again or even shared packages between those
>>> configs.
>>
>> ?Buildroot supports an external toolchain, but it isn't easy to create one.
>> The easiest is to use a crosstool-NG toolchain: build it, install it in some
>> central place, and use it as an external toolchain from buildroot.
>>
>> ?It would be nice if buildroot also supported creation of an external
>> toolchain (based on an internal toolchain config). ?The toolchain is currently
>> built in output/host/usr/... and is not relocatable, so it's difficult to
>> share it between different buildroot builds.
>>
> HI Arnout,
>
> I use the internal buildroot toolchain as an external toolchain all the
> time. I first checkout the buildroot tree into the ....tools directory.
> I select some defaultconfig, then do a make menuconfig and remove
> everything but the toolchain building. The make then trundles for a long
> time and finally I get a toolchain. I can easily change toolchain
> options, if the target system needs something not in the default.
>
> Then I checkout another buildroot tree into a working directory, and use
> the make defaultconfig. Then I make menuconfig and set it up using the
> newly created tools tree toolchain as an external toolchain. This speeds
> up the builds in the working directory, and I don't have to worry about
> the dreaded "make clean" problem of wiping the tools.
>
> More than one working buildroot configuration can use the same tools, as
> long as the same tool options are used in all "parallel" working trees.

Correct, but this doesn't work if the original toolchain build
location is not present (for example because you removed it, or
because you try your toolchain on another machine).

Best regards,
Thomas

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Michael S. Zick]

On Wed September 28 2011, Thomas De Schampheleire wrote:
> Correct, but this doesn't work if the original toolchain build
> location is not present (for example because you removed it, or
> because you try your toolchain on another machine).
> 

I have noticed the same behavior in general over my past 50 years 
of doing computer work -

Whenever I remove software, it quits working.
;-)

Sheese, you would think that after 50+ years of computer advances,
they would have "fixed" that behavior.

Mike

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Bryan Hundven]

On Wed, Sep 28, 2011 at 2:02 PM, Michael S. Zick <minimod@morethan.org> wrote:
> On Wed September 28 2011, Thomas De Schampheleire wrote:
>> Correct, but this doesn't work if the original toolchain build
>> location is not present (for example because you removed it, or
>> because you try your toolchain on another machine).
>>
>
> I have noticed the same behavior in general over my past 50 years
> of doing computer work -
>
> Whenever I remove software, it quits working.
> ;-)
>
> Sheese, you would think that after 50+ years of computer advances,
> they would have "fixed" that behavior.
>
> Mike
(oops, I did reply, not reply-all. Sorry Mike)

Lol! I hate it when that happens! :)

-Bryan

[Buildroot] Creating an external toolchain [was: Re: Antw:Re: Antw: Antw:Re: libgcc build fails on Fedora15]

[Grant Edwards]

On 2011-09-28, Steve Calfee <stevecalfee@gmail.com> wrote:

>> Buildroot supports an external toolchain, but it isn't easy to create
>> one.  The easiest is to use a crosstool-NG toolchain: build it,
>> install it in some central place, and use it as an external toolchain
>> from buildroot.
>> 
>> It would be nice if buildroot also supported creation of an external 
>> toolchain (based on an internal toolchain config).  The toolchain is
>> currently built in output/host/usr/... and is not relocatable, so
>> it's difficult to share it between different buildroot builds.

Once upon a time (a couple years ago) I had hacked up buildroot's
toolchain makefiles and then wrapped the whole thing in a shellscript
so that I could use buildroot to build an external toolchain.

I used that for a couple months but then I switched to using
crosstool-NG.  It's just simpler.  I think trying to turn buildroot
into something that can generate external toolchains would be sort of
a duplication of effort.

> I use the internal buildroot toolchain as an external toolchain all
> the time. I first checkout the buildroot tree into the ....tools
> directory. I select some defaultconfig, then do a make menuconfig and
> remove everything but the toolchain building. The make then trundles
> for a long time and finally I get a toolchain. I can easily change
> toolchain options, if the target system needs something not in the
> default.
>
> Then I checkout another buildroot tree into a working directory, and
> use the make defaultconfig. Then I make menuconfig and set it up
> using the newly created tools tree toolchain as an external
> toolchain. This speeds up the builds in the working directory, and I
> don't have to worry about the dreaded "make clean" problem of wiping
> the tools.
>
> More than one working buildroot configuration can use the same tools,
> as long as the same tool options are used in all "parallel" working
> trees.

That sounds sort of like what I did, except I had it wrapped up so
that the "menuconfig" stuff was automated.

-- 
Grant Edwards               grant.b.edwards        Yow! Why don't you ever
                                  at               enter any CONTESTS,
                              gmail.com            Marvin??  Don't you know
                                                   your own ZIPCODE?