[Buildroot] External toolchain built by buildroot no longer supported.

[Buildroot] External toolchain built by buildroot no longer supported.

[Grant Edwards]

As of this commit

  http://git.buildroot.org/buildroot/commit/?id=3b7aee23f2ab732f06b8a090ca002fb102d547ee

use of of external toolchains built by buildroot is no longer
possible.

Are we to assume that crosstool-NG is now the "officially supported"
source for external toolchains?

I've been using external toolchains built by buildroot since it's so
much simpler than using crosstool-NG: you don't have to build and
install buildroot like you do crosstool-NG, and I already have
buildroot under source control.  Now I'll also have to place
crosstool-NG (both sources and installed files) under version control.

I'd just as soon stick with using buildroot toolchains, but it's
starting to feel like swimming against the tide.

When I asked a few months ago if there was any reason I shouldn't use
external toolchains built by buildroot, I was told there were none.

Has that changed?

-- 
Grant Edwards               grant.b.edwards        Yow! Will it improve my
                                  at               CASH FLOW?
                              gmail.com            

[Buildroot] External toolchain built by buildroot no longer supported.

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

 Grant> As of this commit
 Grant>   http://git.buildroot.org/buildroot/commit/?id=3b7aee23f2ab732f06b8a090ca002fb102d547ee

 Grant> use of of external toolchains built by buildroot is no longer
 Grant> possible.

 Grant> Are we to assume that crosstool-NG is now the "officially supported"
 Grant> source for external toolchains?

Long term I think users are better off with using crosstool-NG for their
toolchains, as that has a more active development community. The
buildroot toolchains work, and I do small fixes / version updates, but
noone is really doing active development on them.

As an example, GDB 7.x is out since October, but still not in BR (I had
a quick look, but didn't get it to work).

With that said, I would very much like to support BR toolchains as
external toolchains if it's possible without too many dirty hacks
(sorry, haven't been following the recent discussion about it). Besides
the advantages you listed there's also the fact that it will make
migration easier in the future - E.G.:

BR with internal toolchain -> BR with external BR toolchain -> BR with
crosstool-NG toolchain.

-- 
Bye, Peter Korsgaard

[Buildroot] External toolchain built by buildroot no longer supported.

[Grant Edwards]

On 2010-04-06, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:
>
> Grant> As of this commit
> Grant>   http://git.buildroot.org/buildroot/commit/?id=3b7aee23f2ab732f06b8a090ca002fb102d547ee
>
> Grant> use of of external toolchains built by buildroot is no longer
> Grant> possible.
>
> Grant> Are we to assume that crosstool-NG is now the "officially supported"
> Grant> source for external toolchains?
>
> Long term I think users are better off with using crosstool-NG for
> their toolchains, as that has a more active development community.

That seems to be the case.

> The buildroot toolchains work, and I do small fixes / version
> updates, but noone is really doing active development on them.
>
> As an example, GDB 7.x is out since October, but still not in BR (I
> had a quick look, but didn't get it to work).
>
> With that said, I would very much like to support BR toolchains as
> external toolchains if it's possible without too many dirty hacks
> (sorry, haven't been following the recent discussion about it).

AFAICT, the recent commit relies on the assumption that both --prefix
and --sysroot values are correct and that the "prefix" is a child of
"sysroot".

That's not the case for buildroot toolchains.  They have a prefix of
"/usr" and a sysroot pointing to the output/staging directory.  I'm
guessing that setting the buildroot toolchain's --prefix value to
output/staging/usr should fix the problem, but I'm still a bit fuzzy
on how the recently committed change works.

> Besides the advantages you listed there's also the fact that it will
> make migration easier in the future - E.G.:
>
> BR with internal toolchain -> BR with external BR toolchain -> BR with
> crosstool-NG toolchain.

True.

-- 
Grant Edwards               grant.b.edwards        Yow! My mind is making
                                  at               ashtrays in Dayton ...
                              gmail.com            

[Buildroot] External toolchain built by buildroot no longer supported.

[Yann E. MORIN]

Grant,

On Tuesday 06 April 2010 17:15:25 Grant Edwards wrote:
> On 2010-04-06, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:
> >
> > Grant> As of this commit
> > Grant>   http://git.buildroot.org/buildroot/commit/?id=3b7aee23f2ab732f06b8a090ca002fb102d547ee
> >
> > Grant> use of of external toolchains built by buildroot is no longer
> > Grant> possible.

We've discussed the issue on IRC yesterday evening, and I'm looking
if I can make a quick fix (something in between a proper fix and a
nice hack), but I'm not close to that yet.

> > With that said, I would very much like to support BR toolchains as
> > external toolchains if it's possible without too many dirty hacks
> > (sorry, haven't been following the recent discussion about it).
> AFAICT, the recent commit relies on the assumption that both --prefix
> and --sysroot values are correct and that the "prefix" is a child of
> "sysroot".

No, the other way around: prefix is a parent of sysroot (directory-wise).

> That's not the case for buildroot toolchains.  They have a prefix of
> "/usr" and a sysroot pointing to the output/staging directory.  I'm

Yes, that's because buildroot plays trick with those values. The code dates
back June 2007, and the exact reason for doing so is not yet known.

I'm trying to bring buildroot toolchains more in sync with a /standard/
way of handling paths, but I have to check regressions.

Anyway, I think that 'old' toolchains build prior the change I'm doing
will not work.

> guessing that setting the buildroot toolchain's --prefix value to
> output/staging/usr should fix the problem,

More complex than that, unfortunately... :-( I tried, and it does not
work so far (a few other things to change as well, eg. binutils).

> but I'm still a bit fuzzy on how the recently committed change works.

As I said earlier:
- get the configured prefix   -> CFG_PREFIX_DIR
- get the configured sysroot  -> CFG_SYSROOT_DIR
- subtract configured prefix from configured sysroot, gives relative sysroot
  -> REL_SYSROOT_DIR
- add current prefix to front of relative sysroot  -> SYSROOT_DIR

Yes, it works only for toolchains where sysroot is below prefix.
Yes, it breaks external toolchains build with buildroot.
Yes, I'm trying to fix this. But I won't invest to much time on that code...

> > Besides the advantages you listed there's also the fact that it will
> > make migration easier in the future - E.G.:
> > BR with internal toolchain -> BR with external BR toolchain -> BR with
> > crosstool-NG toolchain.

Well, there are two cases here:
- toolchain built externally: you have the same issues with all toolchain
  'generators': BR, CT-NG, others...
- toolchain built with CT-NG, but *driven* by BR: it's not an external
  toolchain really.

So I'm not sure that is a transition...

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 built by buildroot no longer supported.

[Yann E. MORIN]

Grant,

On Tuesday 06 April 2010 16:41:05 Grant Edwards wrote:
> I've been using external toolchains built by buildroot since it's so
> much simpler than using crosstool-NG: you don't have to build and
> install buildroot like you do crosstool-NG, and I already have
> buildroot under source control.  Now I'll also have to place
> crosstool-NG (both sources and installed files) under version control.

There is also what I call "the hacker's way" to use crostool-NG, where there
is no need to install it, and hwere you can run from the source tree.

  ./configure --local
  make
  ./ct-ng

(See docs/overview.txt if you want to know why I call that "the hacker's way").

Regards,
Yann E. MORIN.

PS. Oh, and by the way, the canonical address for the mailing list is:
    buildroot at busybox.net (at least it's advertised as such on the 
    ML webpage, in the List- headers, and in the welcome message).
YEM.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 built by buildroot no longer supported.

[Grant Edwards]

On 2010-04-06, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
> Grant,
>
> On Tuesday 06 April 2010 16:41:05 Grant Edwards wrote:
>> I've been using external toolchains built by buildroot since it's so
>> much simpler than using crosstool-NG: you don't have to build and
>> install buildroot like you do crosstool-NG, and I already have
>> buildroot under source control.  Now I'll also have to place
>> crosstool-NG (both sources and installed files) under version control.
>
> There is also what I call "the hacker's way" to use crostool-NG, where there
> is no need to install it, and hwere you can run from the source tree.

Yup, I found that right after I posted that message.  That would make
version control simpler.

> PS. Oh, and by the way, the canonical address for the mailing list
>     is: buildroot at busybox.net (at least
>     it's advertised as such on the ML webpage, in the List- headers,
>     and in the welcome message).

I post via gmane.org's nntp server.  If it's posting to the wrong
address, let me know and I'll contact gmane's admin to try to get it
fixed.

-- 
Grant Edwards               grant.b.edwards        Yow! My face is new, my
                                  at               license is expired, and I'm
                              gmail.com            under a doctor's care!!!!

[Buildroot] External toolchain built by buildroot no longer supported.

[Thomas Petazzoni]

Hi Grant,

On Tue, 6 Apr 2010 14:41:05 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> Are we to assume that crosstool-NG is now the "officially supported"
> source for external toolchains?

No. Yann (the author of the commit) and I have started discussing the
issue yesterday evening, and tried to find a satisfying solution. We
hope to get such a solution integrated before 2010.05.

> When I asked a few months ago if there was any reason I shouldn't use
> external toolchains built by buildroot, I was told there were none.
> 
> Has that changed?

No, it hasn't changed. But there are bugs, and we need to fix them.
External toolchain support is still in its early ages, and it needs to
be improved. Your current feedback and comments are therefore very
welcome.

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 built by buildroot no longer supported.

[Grant Edwards]

On 2010-04-06, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:

>>> Grant> use of of external toolchains built by buildroot is no longer
>>> Grant> possible.
>
> We've discussed the issue on IRC yesterday evening, and I'm looking
> if I can make a quick fix (something in between a proper fix and a
> nice hack), but I'm not close to that yet.

I was going try changing the --prefix that buildroot uses to configure
toolchain stuff to be consistent with the --sysroot value but...

>> AFAICT, the recent commit relies on the assumption that both --prefix
>> and --sysroot values are correct and that the "prefix" is a child of
>> "sysroot".
>
> No, the other way around: prefix is a parent of sysroot
> (directory-wise).

For some reason I always have that backwared in my head.

>> That's not the case for buildroot toolchains.  They have a prefix of
>> "/usr" and a sysroot pointing to the output/staging directory.  I'm
>
> Yes, that's because buildroot plays trick with those values. The code
> dates back June 2007, and the exact reason for doing so is not yet
> known.
>
> I'm trying to bring buildroot toolchains more in sync with a
> /standard/ way of handling paths, but I have to check regressions.
>
> Anyway, I think that 'old' toolchains build prior the change I'm
> doing will not work.

No worries.  I'll either use crosstool-NG or we can fix the way
buildroot configures toolchains.

>> guessing that setting the buildroot toolchain's --prefix value to
>> output/staging/usr should fix the problem,
>
> More complex than that, unfortunately... :-( I tried, and it does not
> work so far (a few other things to change as well, eg. binutils).

Let me know if there's anything I can do to help.

-- 
Grant Edwards               grant.b.edwards        Yow! ONE LIFE TO LIVE for
                                  at               ALL MY CHILDREN in ANOTHER
                              gmail.com            WORLD all THE DAYS OF
                                                   OUR LIVES.