Re: toolchain, was Re: bogl: don't know screen type 1
> 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.
Yep sad isnt it, one hope for the port is that several amigans (
trough natami ) and atarians ( trough the coldfire atari project) or
otherwise some miracle happens at freescale and thereby more people
see a reason to run debian on their 68k's,
Question is tho, as the kernel gets more bloated and slower as time
passes, and the packages that run on top, will it even be usable on
those in a few...
Netbsd seems to have a fast kernel. from what little i've booted of it...
2009/9/5 Maxim Kuvyrkov <email@example.com>:
> Finn Thain wrote:
>> But in that post (June 28) Maxim recommends using mainline binutils, and
>> since then we have HJL binutils-126.96.36.199.14 released, "...based on binutils
>> 2009 0722 in CVS on sourceware.org..." So I guess I should start there.
> The last binutils TLS patches went in on 2009-08-26; the patches fixed
> generation of invalid TLS relocations.
>> 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:
> I think GCC 4.4 should be good enough.
>> As for eglibc, there are a number of branches listed here,
>> The question is, which branch, snapshot or release might meet be suitable?
> EGLIBC does not yet have NPTL patches checked in, they are in review on
> libc-ports@. Once the review is finished, I will likely backport the
> patches from EGLIBC trunk to 2.10 branch.
>> 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...
> You will also need a patch for kernel, posted on linux-m68k@.
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to firstname.lastname@example.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html