[sane-devel] Build system issues.

[Chris Bagwell]

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