Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
(There was a fix related to threads and signals.)
Stable kernel 3.2.35
Posted Dec 13, 2012 17:57 UTC (Thu) by mathstuf (subscriber, #69389)
Posted Dec 13, 2012 18:43 UTC (Thu) by mirabilos (subscriber, #84359)
I’m building with Debian-Ports¹ gcc-4.6, which is just much more tested and somewhat bugfixed than Debian gcc-4.7 (and Debian gcc-4.4 which works well too though), but all three are available. GCC upstream is pretty active, although usually on the Coldfire side of m68k from Mikael Petterson, and Andreas Schwab is dealing with eglibc in addition to the toolchain and usually our rescuer.
① Debian-Ports because it’s a build containing patches not in unstable yet, and unlikely to go in before wheezy’s out: a backport of gcc-trunk (or 4.7)’s atomic builtins – used by Qt4 – and a port to FreeMiNT, among others.
Posted Dec 13, 2012 18:48 UTC (Thu) by jrn (subscriber, #64214)
News to me.
Posted Dec 13, 2012 19:18 UTC (Thu) by mathstuf (subscriber, #69389)
Posted Dec 13, 2012 19:41 UTC (Thu) by mirabilos (subscriber, #84359)
Note we *do* add FreeMiNT (m68k-atari-mint, with vendor) target support in order to be able to compile the bootloaders, but the GNU/Linux (and µClinux) support for M68000 and Coldfire is upstream and active.
Posted Dec 13, 2012 20:15 UTC (Thu) by mathstuf (subscriber, #69389)
Posted Dec 13, 2012 20:27 UTC (Thu) by mirabilos (subscriber, #84359)
But other than that, I can’t find anything. *shrug*
Posted Dec 13, 2012 21:11 UTC (Thu) by mirabilos (subscriber, #84359)
It’s not very good:
• hardcoding stuff, #if 0, etc. instead of modularising changes dependent on tigcc target or not
• patching .h files instead of using configure arguments when the latter exist
• patching m68k.h instead of adding the deviations to m68k-ti.h
• disabling a lot of code
I think it’s written by someone(s) who “just get that damn thing to work” instead of being knowledgeable about GCC. But then, I’m not too good in GCC internals either… I guess it’s at its height though: now that GCC will be written in CFrustFrust I expect my skills to get less.
It uses the m68k-*-coff* vendor-triplet which isn’t removed.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds