[Aboriginal] Failures with 1.2.6

[Rob Landley]

New email client! Still setting filters up, and I've got a chunk of old 
email in the old one to get through still...

On 12/06/13 18:54, Patrick Lauer wrote:
> So again I'm testing the new release. One compile failure for armv4eb:
>
>    STRIP -x -R .note -R .comment librt/librt_so.a
>    STRIP -x -R .note -R .comment libc/libc_so.a
> make[1]: 'lib/ld-uClibc.so' is up to date.
>    LD libuClibc-0.9.33.2.so
> libc/libc_so.a(close.oS):(.ARM.exidx+0x0): undefined reference to
> `__aeabi_unwind_cpp_pr0'

Huh, that target's not eabi, it's oabi. It's armv4l done big endian. Odd...

> collect2: ld returned 1 exit status
> libc/Makefile.in:64: recipe for target 'lib/libc.so' failed
> make: *** [lib/libc.so] Error 1
>
> Exiting due to errors (armv4eb simple-cross-compiler uClibc)

Alas, arm big endian never quite worked under qemu. This is a QEMU 
limitation, something to do with I/O translation. Last I heard it still 
wasn't quite there:

http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg03449.html

That board emulation was added because somebody was testing on actual 
arm big endian hardware, and then they went away again. Somebody else 
was testing on an armv5eb but they went away again too. I never had a 
test environment for this.

I note that building a kernel for this requires expanding the kconfig 
patch stuff to make the versatile board yet more versatile. I have a 2/3 
finished patch around here somewhere, but got to the point where it 
wouldn't boot on qemu because of the above "qemu never implemented an 
emulation with all the switches set the right way" issue.

I admit that "known not to work" targets don't get as much attention 
from me as they should, but... I can't test 'em.

> mips64 still not booting:
>
> VFS: Mounted root (squashfs filesystem) readonly on device 3:0.
> Freeing YAMON memory: 956k freed
> Freeing unused kernel memory: 204K (ffffffff8047d000 - ffffffff804b0000)
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a
>
> Rebooting in 1 seconds..

My very vague understanding of mips64 is:

Long ago, somebody made the first 64 bit mips workstation (possibly 
early irix stuff before SGI wandered away from workstations), and that's 
what I was originaly targeting with that. It was almost immediately 
abandoned, and bit-rotted badly in the kernel because it never sold well 
to begin with and then nobody used it for years.

More recently, everything's going 64 bit and that includes mips, so they 
did a _different_ 64 bit implementation. I'm not sure what changed, but 
I need to retarget this with a different configuration somehow.

There's also a mips32 target that differs from mips-r4k, which I'd like 
to add support for. Unfortunately, I don't know enough about mips. Happy 
for somebody who does to point me in the right direction on either one.

I can dig into mips64 and try to get it working again, but I'd like more 
information about what I should be targeting there. Specifically, in 
Linux is CONFIG_CPU_MIPS64_R1=y still right, and in uClibc is 
CONFIG_MIPS_N64_ABI=y and CONFIG_MIPS_ISA_MIPS64=y still relevant? (I 
vaguely recall the N64 thing is old and busted...)

> And sparc still having compiler problems:
> (sparc:1) /home # ^[[67;19Rgcc -s /usr/src/thread-hello2.c -lpthread -o
> /tmp/hello
> (sparc:1) /home # ^[[67;19R/tmp/hello
>
> /tmp/hello: symbol '__gcc_personality_v0': can't handle reloc type 0x17
> (sparc:1) /home # ^[[67;19Rexit
> sd 0:0:0:0: [sda] Synchronizing SCSI cache
> reboot: Restarting system

Odd, I've built the whole of linux from scratch under sparc.

Now admittedly there's a problem with either the kernel or qemu that 
leads to qemu-system-sparc hanging if the host system is doing anything 
else. (Some sort of race condition where something doesn't happen fast 
enough and then never happens, or some such. I forget if it's spinning 
at 100% cpu or hung, haven't tracked it down...)

Lemme try to reproduce this one.

> I also saw one transient failure with the x86_64 target, but couldn't
> reproduce it (crash on shutdown).

I've seen that too, can't reproduce it either. I believe the qemu guys 
are aware of it, but more information's usually helpful...

> All tests done on x86_64 and qemu-1.6.1

There's a new one out I need to poke at...

Sorry, my big "catch up on everything" push ran into me coming down with 
a horrible cold December 2nd that lasted for TWO WEEKS. Still not 
entirely coherent, but recovered enough I'm starting to poke at stuff again.

Thanks,

Rob

(Oh, PS. I tried your gentoo bootstrapping thing and it made it a 
largeish way before dying when it finally tried to build something 
against the new glibc. I think it was my toolchain wrapper screwing 
stuff up, I'm halfway through the rewrite to allow musl, I'll use this 
as a test case when I get back to that. Thanks for the pointer.)

 1387155198.0