Re: [9fans] crosstool fails on gentoo

Re: [9fans] crosstool fails on gentoo

[Enrico Weigelt]

* Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:

> On Wednesday 28 May 2008 18:52:14 Lance Spaulding wrote:
> > I'm trying to use crosstool-ng to build an ARM toolchain but if fails
> > with the following error message:
> > [ALL  ]    *** [Gentoo] sanity check failed! ***
> > [ALL  ]    *** libtool.m4 and ltmain.sh have a version mismatch! ***
> > [ALL  ]    *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.24 Debian 1.5.24-1") ***
>
> This was already reported a few days ago:
> http://sourceware.org/ml/crossgcc/2008-05/msg00080.html
>
> > It looks like several people have ran into this error on gentoo but I
> > haven't been able to find a solution anywhere (and got no replies to
> > this question in the gentoo forums).  Anyone have a fix for this?
>
> As suggested by Enrico in that message: "we should recreate the autotools+libtool
> stuff before compiling."

Right, manually running autoreconf -fi && libtoolize on the already uncompressed
tree fixed it for me.

Of course this manual hack is ugly, it should be done automatically after
decompression.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] crosstool fails on gentoo

[Uriel]

Thanks for reminding us how boring and sad life in Plan 9 is without
the sadomasochistic joys and pleassures of crosscompiling in the holy
gnu/auto*hell land.

Specially loved the line:

>> > [ALL  ]    *** [Gentoo] sanity check failed! ***

Wonder if they had Einstein's definition of insanity in mind... the
(open and closed source) software industry certainly could make a good
textbook example... maybe they will use it for the next DSM.

uriel

On Sun, Jun 1, 2008 at 5:12 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
>
>> On Wednesday 28 May 2008 18:52:14 Lance Spaulding wrote:
>> > I'm trying to use crosstool-ng to build an ARM toolchain but if fails
>> > with the following error message:
>> > [ALL  ]    *** [Gentoo] sanity check failed! ***
>> > [ALL  ]    *** libtool.m4 and ltmain.sh have a version mismatch! ***
>> > [ALL  ]    *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.24 Debian 1.5.24-1") ***
>>
>> This was already reported a few days ago:
>> http://sourceware.org/ml/crossgcc/2008-05/msg00080.html
>>
>> > It looks like several people have ran into this error on gentoo but I
>> > haven't been able to find a solution anywhere (and got no replies to
>> > this question in the gentoo forums).  Anyone have a fix for this?
>>
>> As suggested by Enrico in that message: "we should recreate the autotools+libtool
>> stuff before compiling."
>
> Right, manually running autoreconf -fi && libtoolize on the already uncompressed
> tree fixed it for me.
>
> Of course this manual hack is ugly, it should be done automatically after
> decompression.
>
>
> cu
> --
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT service - http://www.metux.de/
> ---------------------------------------------------------------------
>  Please visit the OpenSource QM Taskforce:
>        http://wiki.metux.de/public/OpenSource_QM_Taskforce
>  Patches / Fixes for a lot dozens of packages in dozens of versions:
>        http://patches.metux.de/
> ---------------------------------------------------------------------
>
>

Re: [9fans] crosstool fails on gentoo

[ron minnich]

actually there is a kind of interesting trend I'm noticing in the open
source world. Not a good one.

The OLPC has managed the accomplishment of booting 2-3x slower on
linux than xp, and the environment is slow as snails.

open office is bigger, slower, and buggier in my experience than MS office.

I keep reviewing papers that want to simplify things by ... adding
another layer of software!

I just reviewed another paper that was more or less changing something
about a process. In Plan 9, you add a new ctl command. In linux, you,
what else? add a new system call.

The OSS world has built such a complex house of cards that the only
thing people know to do is add more stuff to make it simpler. And we
can see how well that's working.

It's quite a comment on the state of play that the OLPC guys, to
improve the system overall, had to dump Linux for Windows. On the
other hand, if you've used an OLPC, it makes some sense -- great
machine, dog slow. For no reason: inferno runs on it like a bat.

ron

Re: [9fans] crosstool fails on gentoo

[erik quanstrom]

> I keep reviewing papers that want to simplify things by ... adding
> another layer of software!

evidently, someone's only handing you the first halves of papers.
the second halves describe how the original layer was simplified by
not needing to worry at all about ...

oh, wait.  my bad.  never mind.

- erik

Re: [9fans] crosstool fails on gentoo

[Eric Van Hensbergen]

On Mon, Jun 2, 2008 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote:
>
> I keep reviewing papers that want to simplify things by ... adding
> another layer of software!
>

That's a really great observation.  I see it all the time as well, for
some reason simplification has come to mean add new layers of
abstraction.  But it is a false simplification, it may simplify the
API, but the overall system complexity increases (and usually lead to
a decrease in system efficiency).  All productivity factors become
harder (development may be easier, but debugging, performance
debugging, and management typically become more difficult).

Someone really needs to remind folks that "system simplification"
involves a reduction in the number of layers, not an increase in them.

             -eric

Re: [9fans] crosstool fails on gentoo

[Uriel]

Oh, but Sun (who else?) has the solution! When I was speaking at
FOSDEM I came across a Dtrace guy.

He was boasting about how wonderful it was to be able to debug and
profile stuff with this huge kernel hack (third biggest subsystem in
the Solaris kernel, forgot exactly how many, but a few hundred
thousand lines of code). In the end to do stuff 99% of which can be
done in Plan 9 with iostat and acid, and the other 1% can be done with
print statements and careful thought.

But no, he told me, they needed this whole new layer of complexity
(IIRC it includes even a bytecode interpreter/compiler inside the
kernel), because I didn't understand how hard it had become to debug
software this days, you had a bug, and you had to go from apache, to
the Java Application Server, to Oracle, to the file system, etc, etc.
millions and millions of lines of code, and it had become impossible
to debug or profile applications anymore, because the issue could be
anywhere in this huge stack... so what they do? they add *yet another
layer of complexity so you can look at all that stuff at the same
time*.

And even more funny was to see the BSD and Lunix folks falling all
over themselves to be the first ones to get the same thing for their
systems.

The idea of simple and sane interfaces between simple and carefully
designed components is totally lost, it is all about extensibility
(XML!) and 'standards' (more XML!), and if you want to make things
faster, of course the solution is to add a huge layer of caches and
other magic... (I still laugh every time I think of distcc)

But the worst is when they say 'ok, this has got out of hand, we have
to go back and start from scratch'. They end with epitomes of 'second
system syndrome', as seen in apache 2. which is about a hundred times
more complex than apache 1, and adds a dozen new layers of abstraction
(in the name of performance, portability and generality, of course!),
Firefox (I stopped counting millions of lines of code a while ago),
Java, and so many others.

But enough ranting and rambling for today, just remember what Gordon
Bell said, because nobody else will:

"The cheapest, fastest, and most reliable components are those that
aren't there."

Peace

uriel

On Mon, Jun 2, 2008 at 10:09 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Mon, Jun 2, 2008 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote:
>>
>> I keep reviewing papers that want to simplify things by ... adding
>> another layer of software!
>>
>
> That's a really great observation.  I see it all the time as well, for
> some reason simplification has come to mean add new layers of
> abstraction.  But it is a false simplification, it may simplify the
> API, but the overall system complexity increases (and usually lead to
> a decrease in system efficiency).  All productivity factors become
> harder (development may be easier, but debugging, performance
> debugging, and management typically become more difficult).
>
> Someone really needs to remind folks that "system simplification"
> involves a reduction in the number of layers, not an increase in them.
>
>             -eric
>
>

Re: [9fans] crosstool fails on gentoo

[erik quanstrom]

> But no, he told me, they needed this whole new layer of complexity
> (IIRC it includes even a bytecode interpreter/compiler inside the
> kernel), because I didn't understand how hard it had become to debug
> software this days, you had a bug, and you had to go from apache, to
> the Java Application Server, to Oracle, to the file system, etc, etc.
> millions and millions of lines of code, and it had become impossible
> to debug or profile applications anymore, because the issue could be
> anywhere in this huge stack... so what they do? they add *yet another
> layer of complexity so you can look at all that stuff at the same
> time*.

what happened to interfaces?  what good is a software layer —
or a kernel, even — if i have to chase bugs "through" them.
if this is the case they're not hiding anything from me.

it used to be that even a function had to hide something to
earn its keep.

- erik

Re: [9fans] crosstool fails on gentoo

[Uriel]

> what happened to interfaces?  what good is a software layer —
> or a kernel, even — if i have to chase bugs "through" them.
> if this is the case they're not hiding anything from me.
>
> it used to be that even a function had to hide something to
> earn its keep.

We got mmap, ioctl, and xml now, and they are all *extensible* no need
for any pesky 'interfaces' anymore.

uriel

> - erik
>
>
>

Re: [9fans] crosstool fails on gentoo

[Roman Shaposhnik]

On Mon, 2008-06-02 at 22:37 +0200, Uriel wrote:
> He was boasting about how wonderful it was to be able to debug and
> profile stuff with this huge kernel hack (third biggest subsystem in
> the Solaris kernel, forgot exactly how many, but a few hundred
> thousand lines of code). In the end to do stuff 99% of which can be
> done in Plan 9 with iostat and acid, and the other 1% can be done with
> print statements and careful thought.
>
> But no, he told me, they needed this whole new layer of complexity
> (IIRC it includes even a bytecode interpreter/compiler inside the
> kernel), because I didn't understand how hard it had become to debug
> software this days, you had a bug, and you had to go from apache, to
> the Java Application Server, to Oracle, to the file system, etc, etc.
> millions and millions of lines of code, and it had become impossible
> to debug or profile applications anymore, because the issue could be
> anywhere in this huge stack... so what they do? they add *yet another
> layer of complexity so you can look at all that stuff at the same
> time*.
>
> And even more funny was to see the BSD and Lunix folks falling all
> over themselves to be the first ones to get the same thing for their
> systems.

DTrace is an interesting example. I'd be the first one to agree with
you, if it wasn't for the fact that it *is* useful for *me*. It just
is. And it is useful at exactly the right level -- the level of a
simple tool. Like awk or sed. Its like a protective suit for
walking in sh^H^Hmud -- all I care about is that it doesn't leak
and doesn't make me sweat. If its engineering is complex -- well,
it has to interface with that gooey stuff on the outside after all.
I think I'll drop this analogy now (too much worrying about ISS
and the little accident that they almost had there) but I hope
you'll get the idea?

Of course, I'd much rather use Plan9 and not need that kind of
technology. The guy was right, thought. unless Oracle gets ported
to Plan 9 (and somehow magically gets cleansed along the way) there's
no way for the simple sane system to shine. I guess it really is
a bit of chicken and the egg problem.

> The idea of simple and sane interfaces between simple and carefully
> designed components is totally lost, it is all about extensibility
> (XML!) and 'standards' (more XML!), and if you want to make things
> faster, of course the solution is to add a huge layer of caches and
> other magic...

Agreed 100%

>  (I still laugh every time I think of distcc)

I don't understand this point. Would you like it better it was a
services you get out of nodes who export their "compile/link"
interface into your namespace?

> But enough ranting and rambling for today, just remember what Gordon
> Bell said, because nobody else will:
>
> "The cheapest, fastest, and most reliable components are those that
> aren't there."

Couldn't agree more!

Thanks,
Roman.

Re: [9fans] crosstool fails on gentoo

[Iruata Souza]

On Mon, Jun 2, 2008 at 7:32 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Mon, 2008-06-02 at 22:37 +0200, Uriel wrote:
>> *yet another  layer of complexity so you can look at all that stuff
>> at the same time*.
>>
> all I care about is that it doesn't leak

I don't have any solaris boxes to play now, but I remember when taking
a dtrace course - more or less two years ago - that I managed to see
the performance of a nice machine go down only by setting all it's
tracing points. I know that this could be considered normal if it
wasn't for the fact that, with two xterms opened, the one which
started dtrace, after a series of ^C, had 'transfered' to it the
command-line history of the other xterm. It was a peculiar situation
since the instructor was telling us about the non-intrusiveness of the
tool.

iru

Re: [9fans] crosstool fails on gentoo

[ron minnich]

On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:

> I don't have any solaris boxes to play now, but I remember when taking
> a dtrace course - more or less two years ago - that I managed to see
> the performance of a nice machine go down only by setting all it's
> tracing points. I know that this could be considered normal if it
> wasn't for the fact that, with two xterms opened, the one which
> started dtrace, after a series of ^C, had 'transfered' to it the
> command-line history of the other xterm. It was a peculiar situation
> since the instructor was telling us about the non-intrusiveness of the
> tool.
>

it's worth reading the papers. Dtrace is quite capable.

But look at the issues. You are taking a piece of code and splicing in
another piece of code. It can get fun. What if someone was running the
code you are splicing (think: SMP). What about time to remove it: make
sure that (a) nobody is running the spliced in code (how do you do
that in the general case) and (b) nobody is trying to run where you
are putting the code back. What if the original code had an INT
instruction? What if it tickled an  IRQ? What if code you spliced in
takes a fault?

Check out the kprobes device in linux to see how nasty it can get.

At the same time, people delivering software to end users make good
use of dtrace, so it's kind of hard to fault Sun for putting it in
there -- they do have paychecks to hand out. And I expect that lots of
customers demand that it stay in there ...

ron

Re: [9fans] crosstool fails on gentoo

[Iruata Souza]

On Mon, Jun 2, 2008 at 8:21 PM, ron minnich <rminnich@gmail.com> wrote:
> On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:
>
>> I don't have any solaris boxes to play now, but I remember when taking
>> a dtrace course - more or less two years ago - that I managed to see
>> the performance of a nice machine go down only by setting all it's
>> tracing points. I know that this could be considered normal if it
>> wasn't for the fact that, with two xterms opened, the one which
>> started dtrace, after a series of ^C, had 'transfered' to it the
>> command-line history of the other xterm. It was a peculiar situation
>> since the instructor was telling us about the non-intrusiveness of the
>> tool.
>>
>
> it's worth reading the papers. Dtrace is quite capable.
>
> But look at the issues. You are taking a piece of code and splicing in
> another piece of code. It can get fun. What if someone was running the
> code you are splicing (think: SMP). What about time to remove it: make
> sure that (a) nobody is running the spliced in code (how do you do
> that in the general case) and (b) nobody is trying to run where you
> are putting the code back. What if the original code had an INT
> instruction? What if it tickled an  IRQ? What if code you spliced in
> takes a fault?
>
> Check out the kprobes device in linux to see how nasty it can get.
>
> At the same time, people delivering software to end users make good
> use of dtrace, so it's kind of hard to fault Sun for putting it in
> there -- they do have paychecks to hand out. And I expect that lots of
> customers demand that it stay in there ...
>

just like many people, I have made good use of dtrace myself. but the
need for a tool like that seems to me one more evidence of the trend
in talk about in your first post. in the pile of layers one has to dig
to find/fix/rework something, sometimes dtrace seems like the better -
or even the only one at hand - thing to deal with it.
put short: dtrace-like tools are good but, in general, having the need
for it is not.

iru

Re: [9fans] crosstool fails on gentoo

[erik quanstrom]

> just like many people, I have made good use of dtrace myself. but the
> need for a tool like that seems to me one more evidence of the trend
> in talk about in your first post. in the pile of layers one has to dig
> to find/fix/rework something, sometimes dtrace seems like the better -
> or even the only one at hand - thing to deal with it.
> put short: dtrace-like tools are good but, in general, having the need
> for it is not.

it's abstractions, all the way down.  at least until
mack burps.  he always does.

- erik

Re: [9fans] crosstool fails on gentoo

[Nick LaForge]

> it's abstractions, all the way down.  at least until
> mack burps.  he always does.
>
> - erik


we don't get upset about the complexity within
hardware abstractions.

i guess, because we don't usually see it?

and, because software is cheap, it tends to be optimized
for the immediate future, to hack and ask questions
later, even if that means exploding complexity into
my face later on

(did i just argue against source code availability?)

though we've come full circle to the original hardware
interface with 'tiny horrible not xen' and the like.  Only
the interface is buggier and slower.

but we're all familiar with buggy and slow hardware too..

Re: [9fans] crosstool fails on gentoo

[Enrico Weigelt]

* Enrico Weigelt <weigelt@metux.de> wrote:

<snip>

uups, seems I've sent my mail to the wrong list ;-o
(now it's clear why nobody responded @ crossgcc list)

Coffe was out at that day ... Sorry for the confusion.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] crosstool fails on gentoo

[Bruce Ellis]

It was good to see Uriel back in action. And the gmail ads never cease
to amaze me ... this is what I got for this e-mail.

    www.constipationMiracleCure.com

brucee

On Thu, Jun 5, 2008 at 9:11 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Enrico Weigelt <weigelt@metux.de> wrote:
>
> <snip>
>
> uups, seems I've sent my mail to the wrong list ;-o
> (now it's clear why nobody responded @ crossgcc list)
>
> Coffe was out at that day ... Sorry for the confusion.
>
>
> cu
> --
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT service - http://www.metux.de/
> ---------------------------------------------------------------------
>  Please visit the OpenSource QM Taskforce:
>        http://wiki.metux.de/public/OpenSource_QM_Taskforce
>  Patches / Fixes for a lot dozens of packages in dozens of versions:
>        http://patches.metux.de/
> ---------------------------------------------------------------------
>
>