[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclibc
Subject:    Didn't I already ask about NTPL build break on x86_64 with 2.6.32?
From:       rob () landley ! net (Rob Landley)
Date:       2011-10-17 2:23:33
Message-ID: 4E9B91A5.5060904 () landley ! net
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]