[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: toolchain, was Re: bogl: don't know screen type 1



The thing is, its been proven that gcc produces slower and slower 68k
binaries, its probably not the linker in binutils at all
see.
http://www.amiga.org/forums/showthread.php?p=519318
and  ( not 100% sure if its the correct thread, but the natami team
have noticed the issue
http://www.natami.net/knowledge.php?b=3&note=2&z=9M0ieT

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?

Cheers
-Spike

2009/9/5 Stephen R Marenka <stephen@marenka.net>:
> 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[2]: *** [stamps/get_udebs-nativehd-stamp] Error 100
>> > > make[1]: *** [_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
>> http://people.debian.org/~smarenka/m68k/tls/
>> is broken according to Kolla:
>> http://lists.debian.org/debian-68k/2009/07/msg00001.html
>>
>> But in that post (June 28) Maxim recommends using mainline binutils, and
>> since then we have HJL binutils-2.19.51.0.14 released, "...based on
>> binutils 2009 0722 in CVS on sourceware.org..." So I guess I should start
>> there.
>>
>> 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:
>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01024.html
>> Presumably not this one?
>> http://people.debian.org/~smarenka/m68k/tls/gcc_patch2
>> (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,
>> http://www.eglibc.org/repository
>> 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.
>
> Peace,
>
> Stephen
>
> --
> Stephen R. Marenka     If life's not fun, you're not doing it right!
> <stephen@marenka.net>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


Reply to: