Re: Static libc.a and weak __pthread_unwind symbol problem

[Bryan Ischo <bryan at ischo dot com>]

On 08/29/11 18:34, Mike Frysinger wrote:
> On Monday, August 29, 2011 19:06:02 Bryan Ischo wrote:
> > On 08/29/11 15:52, Bryan Ischo wrote:
> > > 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!
> > This approach does get past the __pthread_unwind problem but introduces
> > another:
> >
> > /home/bji/buildtools/output/install/stage2/x86_64-unknown-linux-gnu/usr/x86
> > _64-unknown-linux-gnu/bin/ld:
> > /home/bji/buildtools/output/install/stage1/x86_64-unknown-linux-gnu/usr/li
> > b/libpthread.a(pthread_once.o): relocation R_X86_64_32 against
> > `__gcc_personality_v0' can not be used when making a shared object;
> > recompile with -fPIC
> >
> > I'm not sure if I should give up or keep pressing forward.  God knows
> > I've pressed forward through dozens of problems already that I probably
> > should have just given up on, would hate to be finally defeated by this
> > one ...
> just build shared libs and be done.  or dont build shared libs for anything.
> -mike

I would like to do that, but:

- To build glibc shared libs requires gcc's libgcc_s.so
- To build gcc's libgcc_s.so requires glibc shared libs

This is the chicken-and-egg problem that people wrestle with when 
building a cross-compiling GNU toolchain.

I have read instructions that include lots of manual steps of making 
fake .o files, copying files around manually, etc, etc, but am trying to 
implement a solution that just uses configure script and CFLAGS/LDFLAGS 
magic, thus keeping all of the logic within the GNU toolchain instead of 
partially implemented as external processes.

The way that I have figured out to do this is:

1. Build gcc (using system compiler, any C compiler will do) without 
building libgcc_s; this means make gcc and make gcc-install.  The 
resulting gcc can compile object files but cannot link executables or 
shared libraries.
2. Build static glibc using gcc from (1).
3. Build more featureful (but still with some things disabled, as 
necessary) gcc, including libgcc_s created using the glibc from (2).
4. Build complete glibc using gcc from (3).
5. Build complete gcc using glibc from (4).

Of course binutils is in there at the appropriate places, and if you 
want to build for an arbitrary HOST and TARGET, then you have to build 
both a cross-compiler for HOST and for TARGET and run through lots more 
steps to get a toolchain that works on HOST and targets TARGET.  But I 
have a script that does this successfully for { BUILD=x86_64, HOST=i686, 
TARGET=mips } and { BUILD=x86_64, HOST=i686, TARGET=i686 }.  It's just 
trying to do this for { BUILD=x86_64, HOST=x86_64, TARGET=anything } 
that is causing problems because it appears that the way that the x86_64 
version of nptl is implemented in glibc in step 2 does not produce a 
static glibc that can be used in step 3 due to these R_X86_64_32 
relocation record issues.

If it's possible to shorten the steps above and build, say, a complete 
gcc targeting TARGET without having to have a glibc of TARGET, or some 
other shortcut that doesn't need static versions of glibc to bootstrap, 
then I would be happy to hear about it.  But I tried dozens of 
approaches before I finally found the one that is working as I 
described, and I read dozens of different, conflicting, and 
no-longer-working instructions for doing this and I have more confidence 
in my method since it's the only one that I've gotten to work and it 
works identically for TARGET=i686 and TARGE=mips, which gives me 
confidence that it should work for other TARGETs as well.  It's just 
x86_64 static glibc that is causing problems at the moment.

Thanks,
Bryan