# Please test sane cvs - soname of backend libs

Oliver Rauch (oliver.rauch@Wolfsburg.DE)
Sat, 20 Nov 1999 10:34:03 +0100

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Bernd Schroeder: "Re: Microtek Scanmaker changes colors"
- Previous message: Kevin Dalley: "Numbering schemes for snapshots"
- Next in thread: Petter Reinholdtsen: "Re: Please test sane cvs - soname of backend libs"
- Reply: Petter Reinholdtsen: "Re: Please test sane cvs - soname of backend libs"
- Reply: Oliver Rauch: "Re: Please test sane cvs - soname of backend libs"

Hi,

I made a change to the ltmain.sh in the sane cvs DEVEL_1_9:

I want to explain the background first:
The backend libs of sane are placed in an own subdir "sane" in a "libs" directory.
In the upper "libs" directory there is a link "libsane.so.*" -> "./sane/libsane-dll.so.*".
(on some systems it is not "so", the correct name is given by libtool).

This is the standard installation. This way the dynamic library loader is
loaded when a frontend opens libsane.so . SANE is designed that
a frontend can open any sane backend as libsane.so.*, only the link in the
"libs" directory has to be changed.
But that does not work with exisiting sane versions.

The problem is that the internal names of the shared libraries (sonames)
are equal to the backend library name, but the name of the sane libraryies
have to be "libsane.so.*" (or e.g. "libsane.sl.*) instead of "libsane-umax.so.*"

A frontend that links with "-lsane" agains the link "..../libs/libsane.so.*"
does not store the filename "libsane.so.*" to open the library when executed,
it stores the internal name of the shared library (soname) and in the standard
case that is "libsane-dll.so.*".

So if you link a frontend with "-lsane" you are not able to repleace
libsane-dll.so by an other sane backend because the frontend only
wants to open "libsane-dll.so.*".
The second problem is that the real libs are placed in a subdirectory
of a libs directory where the shared library loader normally does not
search.
This is the reason that e.g. xsane does not start when you did not
add the path of the sane libs to (on linux) /etc/ld.so.conf

So I added the following line to ltmain.sh:

soname=`echo $soname | sed -e "s/libsane-[A-Za-z0-9]*/libsane/g"`

it removes the backend extension form the soname:
libsane-Test7237.so.* -> libsane.so.*

I tested it with linux (SuSE 6.2) and it works fine.

I want to know if this solves the described problems on all systems.

A simple test is:

$ldd /path_to/xsane
...
libsane.so.1 => /usr/local/lib/libsane.so.1 (0x40287000)
...
(that is correct)

$ldd /path_to/xsane
...
libsane-dll.so.1 => /usr/local/lib/sane/libsane-dll.so.1
...
(that is the current, wrong situation)

Bye
Oliver

    --
    Homepage:       http://www.wolfsburg.de/~rauch
    sane-umax:      http://www.wolfsburg.de/~rauch/sane/sane-umax.html
    xsane:          http://www.wolfsburg.de/~rauch/sane/sane-xsane.html
    E-Mail:         mailto:Oliver.Rauch@Wolfsburg.DE

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

     Next message: Bernd Schroeder: "Re: Microtek Scanmaker changes colors"
     Previous message: Kevin Dalley: "Numbering schemes for snapshots"

     Next in thread: Petter Reinholdtsen: "Re: Please test sane cvs - soname of backend libs"
     Reply: Petter Reinholdtsen: "Re: Please test sane cvs - soname of backend libs"
     Reply: Oliver Rauch: "Re: Please test sane cvs - soname of backend libs"