status of 0.9.30 release

[Rob Landley]

On Sunday 07 September 2008 02:47:49 Carmelo Amoroso wrote:
> Rob Landley wrote:
> > On Wednesday 27 August 2008 05:41:14 Bernhard Reutner-Fischer wrote:
> >> On Wed, Aug 27, 2008 at 11:32:30AM +0200, Natanael Copa wrote:
> >>> Hi,
> >>>
> >>> Were there any plans for a 0.9.30 release before the NPTL merge?
> >>>
> >>> What is the status of the 0.9.30 release?
> >>
> >> vapier would know, ISTR that he was the designated RM.
> >>
> >> What are the outstanding regressions versus 0.9.29 on your arch? i386
> >> seems to be in a good shape, AFAICS. Perhaps it would be nice to look
> >> at the open issues in mantis and fix a couple of them for .30-rc1.
> >> Just a thought..
> >
> > I'm interested in finding regressions too, because I'm seriously
> > considering putting out a .30 of my own just so there's a known set of
> > bugs to test against.  (Considering that nothing's been checked into the
> > repository for two weeks, this seems like a nice point to do it...)
>
> I agree, I don't see any real issues for postponing to ship a .30 release
> just now.

I've found a few, starting with the fact that it doesn't seem to build on 
mips:

  CC libc/stdlib/__cxa_finalize.os
In file included from libc/stdlib/__cxa_finalize.c:8:
libc/stdlib/_atexit.c: In function '__cxa_finalize':
libc/stdlib/_atexit.c:205: warning: implicit declaration of function 'typeof'
libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
libc/stdlib/_atexit.c:205: error: '__prev' undeclared (first use in this 
function)
libc/stdlib/_atexit.c:205: error: (Each undeclared identifier is reported only 
once
libc/stdlib/_atexit.c:205: error: for each function it appears in.)
libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
libc/stdlib/_atexit.c:205: error: expected ';' before '__prev'
libc/stdlib/_atexit.c:205: error: invalid lvalue in asm output 0
make: *** [libc/stdlib/__cxa_finalize.os] Error 1

Working on it...

> I stopped for a while nptl merge because involved in kernel stuff,
> but I'll go back to uclibc next week.

I'm looking at the -svn version because 0.9.29 doesn't have TLS and current 
glibc absolutely won't build on a host that doesn't have TLS.  (Yes, even 
when trying to cross-compile it.)  This means you can't cross compile from a 
uClibc system to a glibc system, so you can't build Linux From Scratch 6.3 
under FWL 0.9.0.

I realize that moving to svn doesn't inherently solve that, but if I'm 
contemplating patching the heck out of something (I don't need NPTL, just 
TLS), then more than year old version probably isn't the best basis for it.

> As you have seen, I've fixed a problem in ntpl static link.

Which nptl branch is this?  The sjhill one that only does super hitachi, the 
arm one from the code sourcery guys, or the other one?  To be honest, I 
haven't looked at any of those this year because they all seem totally 
stalled.

> I've discovered similar problrms on trunk (using linuxthreads.old) at least
> on sh4 (but I think it's a common problem).

I don't have an emulator I can run an sh4 linux kernel under.  I've build an 
sh4 cross compiler and uClibc (0.9.29) based root filesystem with busybox and 
a native toolchain, but qemu 0.9.1 system emulation only has a toy sh4 board 
that nobody knows how to make work and doesn't have any interesting hardware 
attached to it anyway.  (The systems I'm using have a virtual hard drive and 
network card so I can build natively under 'em using distcc to call out to 
the cross compiler.  The qemu sh4 emulation I can't even get to boot to a 
shell prompt via serial console.)

> I'll come with a test case soon, but being this issue affecting static
> binaries, I don't think it can delay .30 release.

I had a 0.9.29 patch required to make static binaries work, i dunno if current 
svn still needs it...  Haven't looked yet.

> I don't know Mike's plan, but he is silent since a long time.

I no longer particularly care.  It's been longer than Erik ever went without a 
release, I'm stabilizing an -svn fork for my own use and putting a tarball 
_somewhere_ I can point to and go "this is what I'm using".  It can be -rc1, 
or a renamed nightly snapshot.

(I'll send _myself_ cake when it's over.  Sheesh.)

> > I was working on this last week, but upgrading my laptop to Kubuntu 8.04
> > knocked me offline for a week.  Back now. :)
> >
> > Right now, I'm upgrading my Firmware Linux targets from 0.9.29 to svn. 
> > I'll let you know what breaks, and hopefully patch it up for a quick .30.
> >  I should be able to test x86, x86-64, mips (both endiannesses), arm
> > little endian, and powerpc.  (And maybe sparc if it suddenly decides to
> > work, but it didn't under 0.9.29.)
>
> I'll try to test sh4 on trunk too.

Cool.  Let me know how it goes...

Rob