On Wed, Oct 20, 2010 at 03:53:15PM -0400, Rich Mattes wrote: > Hi all, > > 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[1]. The beginning of the several-lines-long > gcc command looks like: > > gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs > -Wl,-dynamic-linker=/lib/ld-linux.so.3 > > 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 > anywhere yet. 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 previous glibc". 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. Regards, Lluís. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
