And Bernhard is uClibc maintainer!

[Rob Landley]

On Monday 20 October 2008 16:45:17 Bernhard Reutner-Fischer wrote:
> >Yay Bernhard!  He cutteth releases.
>
> We aim for cutting an -rc3 this week which will be based off current
> trunk, fyi.

Woot.

> While there seems to be a regression on armel-oabi ¹) and my proposed
> fix for the coldfire (compile) failure as in ²) is unconfirmed as of
> yet, we are in pretty good shape, AFAICS.
>
> ¹) I only try eabi,

Hard to do an armv4 eabi.  (Although I'm told that circa armv7 or so you _can_ 
finally build everything with thumb2 and have it work.  Haven't tried.  I 
should re-subscribe to the arm kernel mailing list...)

> with the current stable release of gcc, i.e. 4.3.2 
> or, alternatively, trunk. No idea if Rob applied all 039 fixes that are
> currently available against bash-3.2 nor about any other details about
> the toolchain he uses.

Actually, I'm building bash 2.05b, which is noticeably smaller than current 
bash and provides all the functionality needed to build every package I've 
tried so far.

That said, if I boot with init=/bin/ash it only sort of works.  Here's what 
happens:

> $ qemu-system-arm -M versatilepb -nographic -no-reboot -hda
> image-armv4l.ext2 -kernel zImage-armv4l  -append "root=/dev/sda
> console=ttyAMA0 CONSOLE=ttyAMA0 rw init=/tools/bin/ash panic=1
> PATH=/tools/bin" -net nic,model=rtl8139 -net user Uncompressing
> Linux............................................................... done,
> booting the kernel. Linux version 2.6.25.10 (landley at driftwood) (gcc
> version 4.1.2) #1 Mon Oct 20 06:09:31 CDT 2008 CPU: ARM926EJ-S [41069265]
> revision 5 (ARMv5TEJ), cr=00093177
> ...
> boot boot boot boot boot
> ...
> VFS: Mounted root (ext2 filesystem).
> Freeing init memory: 80K
> /tools/bin/ash: can't access tty; job control turned off
> # ls -l
> drwxr-xr-x    2 0        0            1024 Oct 20 11:31
> drwxr-xr-x   13 1000     1000         1024 Oct 20 11:28
> drwx------    2 0        0           12288 Oct 20 11:31 lost+found
> # ls -l

And there it hangs indefinitely, until I kill the emulator.

So the same problem is hitting busybox ash, it's just not crammed to the gills 
with assert() calls to detect it early the way FSF code is.

> ²) http://busybox.net/bugs/view.php?id=3824
> which waits for confirmation by someone who has the actual HW and tests
> the vfork.S hunk, which is just a guesstimate (didn't look at the
> docs).  I did alot of improvement for supporting m68k as well as
> coldfire in buildroot, but i guess normal distros end up doing about
> the same.

Do you have an emulator for these platforms, or are you using real hardware 
for all your tests?

> Current gcc trunk ICEs alot on any m68k even when building 
> a bare system, though so it may be troublesome verifying this unless you
> use 4.3.2 which compiles about fine.

Disable the optimizer and it works for me.  It's the optimizer that's ICE-ing, 
at least the ICEs I've encountered.  (I'm still using the attached patch to 
get m68k to build uClibc.  I'm aware it's not a proper fix.  I could try to 
narrow down a small trigger *.c file test compile as a probe for the ICE, if 
you like...)

> Have fun,
> Bernhard

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alt-uClibc-fixm68k.patch
Type: text/x-diff
Size: 487 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20081020/38154dc1/attachment.bin