https://bugzilla.novell.com/show_bug.cgi?id=765294
https://bugzilla.novell.com/show_bug.cgi?id=765294#c2
--- Comment #2 from Michael Matz 2012-06-04 13:10:38 UTC ---
The problem is the OS ABI notes:
% ldconfig -p | grep libGL.so.1
libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) =>
/usr/lib64/libGL.so.1
libGL.so.1 (libc6,x86-64) => /usr/X11R6/lib64/libGL.so.1
libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
libGL.so.1 (libc6) => /usr/X11R6/lib/libGL.so.1
This is because of elf/cache.c:compare:
/* Sort by most specific hwcap. */
...
if (e2->osversion > e1->osversion)
return 1;
if (e2->osversion < e1->osversion)
return -1;
Hence libraries with no specific osversion requirement land at the end
of all same-named libs in the cache.
That's a target conflict: should libraries not specifying os abi requirements
at all be able to override libs that do specify them? In the libGL case,
clearly yes, both libraries are basically not related with each other,
coming from different vendors and all.
But doing it that way would break the normal usecase of osversion: having
several same-named libs making use of gradually older and older syscalls, back
to a lib which has no special requirements as fallback. That lib should
indeed be at the end of the search list, and it's usually the lib which has
no ABI note, and hence no osversion requirements.
Note: the osversion requirements are encoded in a NOTE program header
resulting from a .note.ABI-tag section. The mesa libs have one, the nvidia
libs don't.
Otherwise relying on aj to decide what should happen in this case.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.