Re: Packaging drivers
Simon Richter <Simon.Richter@phobos.fs.tum.de> writes:
> On 29 May 2000, Andreas Rottmann wrote:
>
> > The drivers reside in
> > /usr/lib/gql/drivers/libgql<soname>-<driverid>.so, wich in fact are,
> > due to the Linux library versioning system, smylinks to
> > libgql<soname>-<driverid>.so.<package-version>.
>
> This is wrong. The actual files should habe at least two version numbers
> and an ELF soname with one version number. ldconfig then creates symlinks
> that are named like the soname field to the newest library it can find.
> When a program is linked, it is linked against the soname of the file
> without a version number (which is a symlink to the version the program
> should be linked against). The first version number is the API version,
> the others arbitrary.
>
OK, I guess I have missed something here, but, however, the whole
thing has nothing to do with ldconfig at all since the drivers are
loaded with libltdl (portable dlopen()-like interface.
> > The symlinking is in this case unecessary, since the drivers are
> > dynamically loaded from within a library, wich has <soname> compiled
> > in and always tries to open libgql<soname>-<driverid>.so.
>
> Which is also wrong, since it doesn't catch API changes like the normal
> Unix library versioning scheme does.
>
Nevertheless it catches API changes... <soname> is the API version
> > 1) The drivers package isn't a -dev package so I get lintian warnings
> > complaining about library symlinks in a non -dev package.
>
> Lintian is correct. A .so -> .so.<api> link is unnecessary when you're not
> linking anything.
>
ACK
> > 2) The symlinks weren't necessary (and aren't beautiful anyway) if I
> > managed to install the "real driver .so" libgql<soname>-<driverid>.so
> > (and not just have it beeing a symlink pointing to the real .so)
>
> This is bad because API changes can happen. IMO the best solution is to
> patch the source to request its libraries with ".so.<apiversion>" and call
> ldconfig on the directory after installing or removing drivers.
>
API changes: see above.
I don't understand why I would have to call ldconfig in this case at
all (the symlinks are always included in the debian package).
Furthermore, your suggested solution is not quite portable, since I
don't have a way to know if .so is the right dynamic object extension
- this is why I'm using libltdl, which opens .la files that point (no
symlink) to the right filename - however the .la filenames don't
include version information, so I included it myself. I need distinct
filenames since there might be multiple library/driver versions
installed, so the library the user program is linked against must be
able to find out "its" driver.
I hope you (or someone else) can tell me what's wrong with the current
(adapted) setup:
~$ dpkg --contents libgql0-driver-pg_0.0.5-4_i386.deb
[snip]
drwxr-xr-x root/root 0 2000-05-29 18:01:51 ./usr/lib/gql/drivers/
-rw-r--r-- root/root 796 2000-05-29 18:01:18 ./usr/lib/gql/drivers/libgql0-pg.la
-rw-r--r-- root/root 122040 2000-05-29 18:01:51 ./usr/lib/gql/drivers/libgql0-pg.so.0.0.0
lrwxrwxrwx root/root 0 2000-05-29 18:01:49 ./usr/lib/gql/drivers/libgql0-pg.so.0 -> libgql0-pg.so.0.0.0
[snip]
code to load the library:
--------
lt_dlsetsearchpath(path.c_str());
modulename = string("libgql") + GQL_SO_VERSION + "-" + id;
module = lt_dlopenext(modulename.c_str());
-------
lt_dlopenext() opens the mentioned .la file.
This is a) lintian-clean b) works (also with multiple versions of the
library/drivers).
Thanks, Andy
--
Andreas Rottmann | Dru@ICQ | 54523380@ICQ | a.rottmann@gmx.at
Pfeilgasse 4-6/725 | A-1080 Wien | Austria | Europe
http://www.8ung.at/rotty | Key is there | gpg (GnuPG) 1.0.1
Fingerprint | 3E9A C485 49A4 1D17 2EA7 2BA7 22AE C9BF 8173 6279
[one of 78,35% Austrians who didn´t vote for Haider!]
Reply to: