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 > _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
