Re: toolchain, was Re: bogl: don't know screen type 1
*hurm* Well if it is the case that some dev at freescale has assumed
that producing binaries in a certain way that makes sense for the
coldfire series ( which might resemble the original enough to make it
seem sensible ) might explain the slowdown were seeing _across the
line_ ( be it amigaos linux or fuckos).
Bernd Roesch ( now included weather he likes it or not, sorry :) has
also made remarks and comparisons about this. As has the amigaos dev's
of ffmpeg, which has made it bleeding clear in the posts linked to
So no the slowdown from 333,340 to 4xx is not only amigaos, its
clearly visible booting the linux kernel too ... .
2009/9/5 mike <email@example.com>:
> The thing is, its been proven that gcc produces slower and slower 68k
> binaries, its probably not the linker in binutils at all
> and ( not 100% sure if its the correct thread, but the natami team
> have noticed the issue
> Including Gunnar Von Boehn in this now, cause they've done alot more
> research, and can probably fill in what freescale have, and havent
> done. I suspect they have been tweaking the code for newer "68k's" or
> coldfires, rather than branching it off?
> 2009/9/5 Stephen R Marenka <firstname.lastname@example.org>:
>> On Sat, Sep 05, 2009 at 01:43:14AM +1000, Finn Thain wrote:
>>> On Tue, 1 Sep 2009, Stephen R Marenka wrote:
>>> > On Tue, Sep 01, 2009 at 12:16:27AM +0200, mike wrote:
>>> > > Btw, i noticed an error
>>> > > http://people.debian.org/~smarenka/d-i/m68k/images/daily/build_nativehd.log
>>> > > E: Couldn't find package libnss-dns-udeb
>>> > > make: *** [stamps/get_udebs-nativehd-stamp] Error 100
>>> > > make: *** [_build] Error 2
>>> > > make: *** [build_nativehd] Error 2
>>> > Yep. debian-installer dailies are now *dead* until we get a modern libc
>>> > working.
>>> I wonder whether there are debian source packages for binutils, gcc and
>>> glibc having TLS/NPTL support for m68k.
>> I'd be surprised if that were the case.
>>> The patches posted to the binutils mailing list are incomplete. The
>>> binutils patch at
>>> is broken according to Kolla:
>>> But in that post (June 28) Maxim recommends using mainline binutils, and
>>> since then we have HJL binutils-18.104.22.168.14 released, "...based on
>>> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start
>>> I understand that the current GCC (4.4) lacks the necessary patches, and
>>> 4.5 is still uncooked (and that's a scary prospect). Can someone confirm
>>> that this is the necessary patch for 4.4:
>>> Presumably not this one?
>>> (and gcc_patch1 is clearly broken... perhaps it was actually the same
>>> thing before being mangled... Stephen, I don't think this "/tls" directory
>>> is helping any.)
>> Shall I remove it then?
>>> Or perhaps there is a known-good gcc 4.5 snapshot (FWIW, I'd much rather
>>> patch a debian compiler instead, which means 4.4 or preferably older.)
>> It would be wonderful to have debian gcc 4.4 building on m68k. It
>> never has.
>>> As for eglibc, there are a number of branches listed here,
>>> The question is, which branch, snapshot or release might meet be suitable?
>>> With this information, I could attempt to build a toolchain from upstream
>>> sources, or figure out whether or not the debian archive has the necessary
>>> source packages...
>> The life is fast ebbing from debian/m68k as far as I can tell. I'm not
>> sure if there is sufficient energy to revitalize it. I'd be delighted to
>> be proven wrong.
>> Stephen R. Marenka If life's not fun, you're not doing it right!
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to email@example.com
>> More majordomo info at http://vger.kernel.org/majordomo-info.html