Bug#156841: glibc_2.2.5-13(alpha/unstable): FTBFS: non-PIC code in a dynamic lib
Ryan,
This doesn't fit with bug #155606 as far as I can tell. That bug would only
occur when a glibc is built with a gcc >= 3.1 and the build log for alpha
claims that gcc 2.95.4 was used. Also, on ppc we never see any breakage in the
glibc build itself when gcc 3.2 is used. Rather when you install the resulting
glibc you will have old binaries unable to resolve certain libgcc related
symbols. Lastly none of these symbols match the ones that ia64 or ppc had to
add to their libgcc-compat patches.
However if you have access to the alpha build machine you can test by
looking the libgcc.a from gcc 2.95.4 and seeing if __divlu, __divqu, __remlu
and __remqu are exported symbols. Then scan all of the binaries on the machine
to there is any undefined references to these symbols. If so it could be the
same bug, but I don't see how it happened unless someone installed a glibc
built with gcc >= 3.1 and your glibc buildroot is leaky grabbing those files.
The debian glibc cvs claims to have a patch for the previous alpha build
failures. I wonder if this could rather be a problem with changes in
the binutils package? Hmmm...actually there doesn't seem to be anything
in the control file for glibc dictating the binutils version which is rather
scary considering all the symbol versioning bugs found lately. How can one
tell which binutils this glibc got built against?
Jack
Reply to: