Description of problem:
A patch to binutils (http://sourceware.org/git/?p=binutils.git;a=commit;h=cd49363b8ae1725522ea29ccc0dda7b138f3d5aa) has introduced an unintended regression in ld.so. Specifically, when an object that has the new ABI header is compared against an object that has *no* ABI header it is considered a mismatch in ld.so.cache. The desired behavior is that no ABI header is treat it as the equivalent of a wildcard.
Version-Release number of selected component (if applicable):
Unknown. Presumably the behavior has been in glibc for a while but only came up as a result of binutils adding the elf fields glibc needed.
Steps to Reproduce:
1. Install a library that is only available via ld.so.cache (EG, /usr/lib/atlas/libf177blas.so). This library will be visable via 'ldconfig -p'.
2. Link an executable with -L/usr/lib/atlas
3. Running the executable will result in libf177blas.so not being found.
4. If you add /usr/lib/atlas to LD_LIBRARY_PATH the executable will work. It's just ld.so.cache that is broken.
Shared library not found.
Dynamic linker finds library, proceeds normally.
Binutils is doing the right thing by marking objects with their ABI, but we can't retroactively fix all the objects built prior to the October/November binutils update. We just need glibc to treat unmarked objects as using the same ABI as objects that are marked.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Working on a fix for this.
Still working on this.
I've been informed that this should be checked in ASAP e.g. tonight or tomorrow.
I can't get it all done tonight, I still need some more testing.
Likely tomorrow morning, and post upstream, and get it into rawhide.
Any other branches that this needs checking into?
Please check in to both f18 updates and rawhide.
Patch sent upstream:
We want to reserve the ld.so.cache value with upstream before we use it.
Upstream accepted the patch.
I'll commit upstream tomorrow.
I'm almost done the rawhide commit, but I've run out of time tonight.
I'll commit rawhide tomorrow morning.
Following the rawhide committ I'll do a larger backport to F18. The F18 backport requires more additional changes and more testing.
The fix for this is in rawhide and thus F19.
Still working on the F18 fix.
Author: Carlos O'Donell <email@example.com>
Date: Fri Feb 8 12:26:12 2013 -0500
ARM: Support loading unmarked objects from cache.
ARM now supports loading unmarked objects from
the dynamic loader cache. Unmarked objects can
be used with the hard-float or soft-float ABI.
We must support loading unmarked objects during
the transition period from a binutils that does
not mark objects to one that does mark them with
the correct ELF flags.
Signed-off-by: Carlos O'Donell <firstname.lastname@example.org>
Can you confirm that you actually see this issue in F18?
The F18 glibc is based on 2.16 which doesn't have any of the code to safely support mixed ABI environments. The 2.16 loader will load any of the objects from any of the ABIs.
Therefore there can be no bug in F18. At best it would be a new feature request for F18.
Can you confirm please?
Have not observed on F18. As long as an F18 doesn't contain the mixed ABI recognition code we no need to do anything there.
Fixed in F-19+