On Wed, Oct 20, 2010 at 03:53:15PM -0400, Rich Mattes wrote:
I chrooted into a failed glibc mockbuild and ran "make" again in the glibc
build directory to get the gcc incantation for libanl.so that has been
causing the glibc build to fail. The beginning of the several-lines-long
gcc command looks like:
gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs
If you remove the "-static-libgcc" flag from the gcc command, libanl.so is
able to build successfully. I don't know why libgcc_eh.a's
__stack_chk_guard isn't resolved by the definition in /lib/ld-linux.so.3,
but the problem can apparently be sidestepped by removing "-static-libgcc"
from the equation entirely.
I figured I'd share my findings in case someone knows how to get around this
from within the makefiles. I'm still hacking at it, but I haven't gotten
I don't know the details in fedora, but you may have a bootstrapping problem,
specially using the -fstack-protector.
If you compile code with -fstack-protector, you have to link with gcc's libssp
(statically or dynamically). If you do that statically to make a shared library
(or a pie executable), you need libssp.a compiled with -fPIC (which may not be usual).
If you want to link dynamically, you will have a glibc shared object linked with
the libssp shared object, which I bet was also linked dynamically with "the
So you may end up with a new libc that was linked with a gcc library that was
linked with an old glibc.
And the "-dynamic-linker" flag does not make gcc or ld read anything at link
time. It simply sets in the ELF where will be the dynamic linker. note that here
it refers to where the dynamic linker will be at run time, and not where it is
now, because your glibc build may be building also the dynamic linker.
I think the only way to break the dependency of glibc binaries (libs or execs)
on gcc libs (that may depend on libc) is to avoid the gcc stack protector. I
don't know another way.