Hi Bernhard, Bernhard Reutner-Fischer wrote, > On Thu, Aug 28, 2014 at 12:31:22PM +0200, Waldemar Brodkorb wrote: > > tst-spin1.c compile breaks with: > > test/nptl/tst-spin1.c:34: undefined reference to `pthread_spin_lock' > > > > pthread_spin_lock and pthread_spin_trylock is missing while > > building sparc. add the meta c files here. > > 1) what about pthread_spin_unlock?
Yeah, I need to check this. I put it on my TODO. > 2) wouldn't it be nicer to teach > libpthread/nptl/sysdeps/sparc/Makefile.arch which of sparc32/sparc64 > it should use? Depends. > 3) As you have seen (and removed the typoed subdirs), there is a > specialization for sparcv9 there which should probably be used. > > Applied the below in the meantime, thanks! Is uCLibc usable and tested in any way for Sparc64? May be I got it wrong. Here how I understand the Sparc architecture stuff: - There are mainly three different instruction sets: SPARCv7 SPARCv8 SPARCv9 SPARCv7 is for older 32 Bit systems and should also work for every other 32 Bit sparc system. SPARCv8 is the preferred 32 Bit instruction set. This is what I test with qemu-system-sparc. And there is SPARCv9 which is used for 64 Bit sparc systems. I use "ultrasparc" gcc optimization for qemu-system-sparc64 and glibc. Using either v9a or v9b doesn't work for Linux for me. And then I have read about SPARCv8+, which can be used for Sparc64 systems with a 32 Bit userland. (like x32 for x86_64?) So what exactly you mean? When just trying to use uClibc for sparc64 with CONFIG_SPARC_V9=y I get following error: libc/sysdeps/linux/sparc/__longjmp.S: Assembler messages: libc/sysdeps/linux/sparc/__longjmp.S:33: Error: invalid operands (*UND* and *ABS* sections) for `*' In glibc __longjmp.S is not used for sparc64, so I am not confident that uClibc is ever used for sparc64. best regards Waldemar _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
