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 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. -mike
> 
> 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.

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 :-)

Cheers,
Carlos.


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