David Engel writes:
> I believe the use of libgdbm.so.2 comes from the fact there was (for a
> short period of time) a version built with ELF libc.so.4 which used
> libgdbm.so.1. I did some checking and unfortunately found that both
> RedHat and Slackware are using libgdbm.so.2.
> 1. Leave our package unchanged and tell users to hand edit their
> binaries which use libgdbm.so.2 to use libgdbm.so.1.
> 2. Add a dummy, "compatibility" libgdbm.so.2 to our package which
> simply loads libgdbm.so.1 at run-time. This dummy library can be
> easily built by running "gcc -shared -o libgdbm.so.2
> -Wl,-soname,libgdbm.so.2 -lgdbm"
> 3. Change our package to use libgdbm.so.2, update any packages which
> use libgdbm and optionally add a compatibility libgdbm.so.1 which
> loads libgdbm.so.2 at run-time.
Couldn't we just add libgdbm.so.2 as a symlink to libgdbm.so.1? On my system
I have both, the Slackware so.2 and the Debian so.1 and it works fine. The
so.2 version is just used for running binaries. The development goes with
the Debian versions. So I think replacing the so.2 version by a symlink
would work, too.
BTW the problem also exists for the libdb library.
Lehrstuhl fuer angewandte Mathematik insb. Informatik
RWTH-Aachen, D-52056 Aachen, Germany