On Thu, Feb 26, 2009 at 11:00 PM, Chris Bagwell <chris at cnpbagwell.com> wrote: > m. allan noah wrote: >> >> On Thu, Feb 26, 2009 at 9:46 PM, Chris Bagwell <chris at cnpbagwell.com> >> wrote: >> >>> >>> And just to be sure; did you also run the "ldconfig -n /usr/lib/sane" >>> step >>> to verify its not ldconfig doing the wrong thing? >>> >> >> now i did, and yes- that is the culprit. >> > > Hmmm, seems maybe its always been this way? ?Although on my system, I'm not > seeing it. > I think I at least now know where that mystery symlink of last backend comes > from: > > /usr/lib/sane/libsane.so.1 -> libsane-xerox_mfp.so.1.1.0 > > > I see references on the net that ldconfig purposely does not update "linker" > symlink (/usr/lib/sane/libsane-backend.so) if it already exists but that the > "soname" (/usr/lib/sane/libsane.so.1 because of patched libtool) is updated > to latest version of "realname" (/usr/lib/sane/libsane-backend.so.1.1.0 in > CVS case) always. ? That correctly describes above symlink > > But your system seems to be not obeying the first part and updating the > "linker" name to a "realname" that also has a matching "soname". ?My system > doesn't seem to be doing that for some reason (Fedora 10). > > Here is an idea to explore... Is there any change your RPM package is > replacing ltmain.sh or libtool when it was compiled? ?I could see how > ldconfig might behavior like your seeing if 1.0.19 backends were installed > with "soname"'s of the form libsane-backend.so.1 but your 1.1.0 backends > were installed with soname's of the form libsane.so.1. >
Its not 'my' rpm- it is the distro's rpm, which happens to be: Fedora 10, tada! Now you can test it too :) allan -- "The truth is an offense, but not a sin"
