[sane-devel] Build system issues.

[m. allan noah]

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"