Way back when, I posted: http://lists.busybox.net/pipermail/uclibc/2011-March/045020.html
Where I said: > LD libpthread-0.9.32-rc3.so > /home/landley/play/aboriginal/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld: > libpthread/nptl/libpthread_so.a(pthread_once.oS): relocation > R_X86_64_PC32 against `__fork_generation' can not be used when making a > shared object; recompile with -fPIC > /home/landley/play/aboriginal/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld: > final link failed: Bad value > > Looks like libpthread_so.a was built without -fpic...? > > This was using a toolchain and config that pthreads.old worked with... And I _think_ somebody emailed me a response, but there's nothing in the list archive. I'm getting back around to poking at NPTL and I'm hitting the bug again, and reading the x86-64 fork.c it's an #include of ../fork.c and the build for it in libpthread/nptl/sysdeps/unix/sysv/linux/x86_64/Makefile.arch has this weird: libc_linux_arch_CSRC = fork.c ... ifeq ($(UCLIBC_HAS_STDIO_FUTEXES),y) CFLAGS-fork.c = -D__USE_STDIO_FUTEXES__ endif CFLAGS-OMIT-fork.c = -DNOT_IN_libc -DIS_IN_libpthread And the actual declaration of the symbol is that it's both hidden and requires relocation and I'm not following everything that's going on here and it's not ringing any bells... Confused, Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
