This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Static libc.a and weak __pthread_unwind symbol problem


On 08/29/11 15:28, Mike Frysinger wrote:
On Monday, August 29, 2011 17:59:00 Carlos O'Donell wrote:
On 8/29/2011 4:53 PM, Bryan Ischo wrote:
On 08/29/11 13:44, Mike Frysinger wrote:
On Monday, August 29, 2011 14:55:48 Bryan Ischo wrote:
I build a purely static version of glibc in an early stage of a
'bootstrapping' process of building gcc, glibc, and binutils as
a cross-compiler.  Then I use that static glibc when building
gcc.  This works fine when the BUILD and HOST are
i686-unknown-linux-gnu, but the pthreads implementation for
x86_64 is different and causes problems.
if you have a static-only glibc, then dont build shared libs with
gcc.  the error you're getting is because you're wrongly trying to
include non-PIC objects in a shared library for a mips target.
like the error told you.
The objects are PIC, the static-only glibc was built with -fPIC and
-DPIC for every object file therein.  The error has something to do
with the R_X86_64_PC32 relocation symbol type, and binutils'
insistence that any symbol with this relocation type be a 'hidden'
symbol.  There are lots of reports of this confusion around on the
'net, because the error reportage by ld is not accurate (it tells to
build the objects PIC when in fact they were and the problem is
elsewhere).

I think I may have mislead when I mentioned the
mips-unknown-linux-gnu target; while this is the eventual target of
the cross-compiler, as a first step I build a 'native' compiler
(BUILD=HOST=TARGET=x86_64-unknown-linux-gnu) incrementally, and this
is when the error in question is occurring.
Just because you compiled with -fPIC doesn't mean that everything
is *always* going to be kosher for PIC. You've got a PC32 relocation
in there which is never going to work. This is just another artifact
of trying to do something which is currently unsupported.
yes, Gentoo carries some patches to fix problems like this in upstream glibc.
not saying this is the case with this issue, just confirming Carlos'
statement.
-mike

Thank you for the information. Is there a general technique for eliminating PC32 relocations?


carlos@systemhalted.org:
 If you hid the pthread symbol then it will be truly undefined and
 at runtime you'll need a shared copy from libpthread.so... which
 whoops, you don't have.

 The real option is to link in libpthread.a IMO which should include
 __pthread_unwind. However, that involves hacking gcc configury

I did try hacking the gcc configuration to force -lpthread when libgcc_s.so was being linked, but that didn't help, I still got the relocation error. Of course, I did that before hiding the __pthread_unwind symbol. Are you saying that both hiding the symbol and forcing libgcc_s.so link to include -lpthread should work? I hope so - I'll try it now!


Thanks,
Bryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]