status of 0.9.30 release

[Carmelo Amoroso]

Rob Landley wrote:
> 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.
> 
Yes, there is just one NPTL branch supporting now, all integrated together,
mips/arm/sh4. Almost synchronized with trunk. Containing the patches
I was referring missing from trunk... at least for sh4 fully tested (LTP too),
really used in a production system from ST's customers.
It seems you have missed a lot of recent works and commit done by Khem and myself.

>> 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.)
>
Don't worry, I've real working sh4 hw with its toolchain. I'll test it.

>> 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
>