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. Chris
