Re: bogl: don't know screen type 1

2009-09-12 Thread fthain
On Fri, 11 Sep 2009, Kolbj?rn Barmen wrote: > On Thu, 3 Sep 2009, mike wrote: > > > I tried to boot 2.6.29 or whatever... It was so slow compared to 2.4 i > > donno what to say, except its crap. Not a surprise if gcc produces > > crappier and crappier 68k binaries anyway. Why the hell isnt fr

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

2009-09-12 Thread fthain
On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote: > Finn Thain wrote: > ... > > > 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/

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

2009-09-14 Thread fthain
On Sun, 13 Sep 2009, Maxim Kuvyrkov wrote: > fth...@telegraphics.com.au wrote: > > > On Sat, 5 Sep 2009, Maxim Kuvyrkov wrote: > > > > > Finn Thain wrote: ... > > > > > > > I understand that the current GCC (4.4) lacks the necessary > > > > patches, and 4.5 is still uncooked (and that's a scar

Re: etch-m68k and newer packages

2009-11-28 Thread fthain
On Fri, 27 Nov 2009, Ingo J?rgensmann wrote: > On Fri, Nov 27, 2009 at 10:10:49AM -0600, Stephen R. Marenka wrote: > > On Fri, November 27, 2009 3:12 am, Ingo J??rgensmann wrote: > > > On a sidenote it seems that Arrakis and Spice aren't building > > > packages anymore. Are they still needed? >

Re: etch-m68k and newer packages

2009-11-29 Thread fthain
On Sun, 29 Nov 2009, Stephen R. Marenka wrote: > > On Sat, November 28, 2009 7:12 pm, fth...@telegraphics.com.au wrote: > > > There are some packages that I'd like to see built under etch-m68k. > > From the gcc-4.2 build failures that Stephen showed us, I have my > > doubts about packages in

Re: Bootstrapping sid (was m68k Debian lenny?)

2010-03-12 Thread fthain
Geert and I wrote a howto for the latter method. (By now it probably needs a few tweaks for recent Debian/Ubuntu releases.) http://www.telegraphics.com.au/~fthain/howto-debootstrap-etch-m68k.txt There was a post on the mailing list reporting that a Net Install for etch-m68k is possible by co

Re: Bootstrapping sid (was m68k Debian lenny?)

2010-03-13 Thread fthain
On Sat, 13 Mar 2010, Stephen R Marenka wrote: > On Sat, Mar 13, 2010 at 05:37:15PM +1100, fth...@telegraphics.com.au wrote: > > BTW, latest upstream binutils and GCC releases already have TLS/NPTL > > support for m68k. The git repos for glibc and Linux appear to have > > TLS/NPTL patches merged

Re: Bootstrapping sid (was m68k Debian lenny?)

2010-03-15 Thread fthain
On Mon, 15 Mar 2010, John Klos wrote: > Hi, > > > I guess I should add that I've never actually tested gcc-4.5. The > > release notes say that the feature is there. > > Ok... So one of the first steps is seeing how difficult it is to get gcc > 4.5 up and running. Sid only has gcc-4.4. Stephe

Re: Question

2010-04-10 Thread fthain
Hi Britt, On Fri, 9 Apr 2010, Britt Dodd wrote: > I absolutely adore the 68k processor, even if it is slow by todays > standards. You can speed it up with an emulator, like aranym or qemu. > I would like to help in any way I can to ensure the survival of > debian-68k. I'd suggest that you t

Re: ARAnyM built packages, and helping buildds along

2010-04-10 Thread fthain
On Sat, 10 Apr 2010, Thorsten Glaser wrote: > Dixi quod > > >Second, I'm in the process of trying to build either gcc-4.4 > > Ugh, it needs newer binutils. I'm not going to do that, I leave that to > the experts. I think sid binutils is available. Stephen? > > >I've thought about uploading

Re: gcc 4.5 and TLS

2010-04-19 Thread fthain
On Mon, 19 Apr 2010, Wouter Verhelst wrote: > Does anyone know what the status of this support is in libc? This was the situation a month ago-- http://lists.debian.org/debian-68k/2010/03/msg00014.html It appears that the eglibc repo has the patches in HEAD now. Finn -- To UNSUBSCRIBE, email

Re: gcc 4.5 and TLS

2010-04-19 Thread fthain
On Mon, 19 Apr 2010, Thorsten Glaser wrote: > Wouter Verhelst dixit: > > >could we look into re-bootstrapping the port and starting to build > > I?m currently building gcc-4.4 and other up-to-date packages. Once I get > gcc-4.4 to work ... we can ask doko to put the patches into 4.4. > > Then

Re: gcc 4.5 and TLS

2010-04-20 Thread fthain
On Tue, 20 Apr 2010, I wrote: > and you need [glibc with NPTL] before you can build gcc with TLS. Well, this isn't quite right. I'm told that you can get __thread support from gcc 4.5 without having to have NPTL support in your libc. Problem is, that compiler will have fixed includes, libgcc,

Re: gcc 4.5 and TLS

2010-04-20 Thread fthain
On Tue, 20 Apr 2010, Thorsten Glaser wrote: > fth...@telegraphics.com.au dixit: > > >Anyway, since these are native builds, steps 3+ need to happen running > >under a kernel with TLS support (which could be built with a plain > >etch-m68k tool chain last time I tried it). You also need the ker

Re: g++-4.4 failings

2010-04-23 Thread fthain
On Fri, 23 Apr 2010, Thorsten Glaser wrote: > Hi, > > I wrote my findings here: > https://bugs.launchpad.net/debian/+source/gcc-4.4/+bug/514579 You said on launchpad, "libgfortran cannot be built multilib because one of the system includes contains inline assembly that is invalid with -mfidoa

Re: g++-4.4 failings

2010-04-24 Thread fthain
On Sat, 24 Apr 2010, Thorsten Glaser wrote: > fth...@telegraphics.com.au dixit: > > >BTW, if it is still there, debian's "m68k-allow-gnu99" patch should be > >removed before it causes problems. > > No. That one can only be removed once eglibc is in unstable, not before > that. (At least from

Re: g++-4.4 failings

2010-04-25 Thread fthain
On Sun, 25 Apr 2010, Gayle Lee Fairless wrote: > [68080] is a Motorola microprocessor chip typically found in Amiga > computers and others. Are you sure? I've never heard of such a device. Anyway, Linux supports 68020 with MMU, 68030, 68040 and 68060 processors. It also supports Coldfire and

Re: 680?0, was Re: g++-4.4 failings

2010-05-18 Thread fthain
On Tue, 18 May 2010, Kolbj?rn Barmen wrote: > However, the speed is not really that impressive yet That is because they use FPGAs (cheap in small quantities, slow, reprogrammable) and not ASICs (cheap in large quantities, fast, not reprogrammable). The speed is actually better than the real th