[Aboriginal] Failures with 1.2.6
rob at landley.net
Sun Dec 15 16:53:18 PST 2013
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: '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
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:
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
> (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.
(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.)
More information about the Aboriginal