Re: Static libc.a and weak __pthread_unwind symbol problem

[Mike Frysinger <vapier at gentoo dot org>]

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

Attachment: signature.asc
Description: This is a digitally signed message part.