This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: libdb and 2 major numbers
- To: Thorsten Kukuk <kukuk@weber.uni-paderborn.de>
- Subject: Re: libdb and 2 major numbers
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 13 May 1998 14:38:38 -0700
- Cc: libc-hacker@cygnus.com
- References: <13658.2264.689245.325565@vt.uni-paderborn.de>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
Thorsten Kukuk <kukuk@weber.uni-paderborn.de> writes:
The problem with this solution is that th soname is wrong. It has to
be libdb.so.2 and not libdb1.so.2.
> - How could I prevent make install to generate a /usr/lib/libdb.so
> file for db ? For db2, it is ok.
Some extra Makefile hacks could do this.
> - gnu/lib-names.h: With this hack, we have 2 entries:
> #define LIBDB1_SO "libdb1.so.2"
> #define LIBDB_SO "libdb.so.3"
> With other solutions, LIBDB_SO could be libdb.so.2, both is bad.
This isn't that bad, I think. If an application really needs this
information it could use
#ifdef LIBDB1_SO
# define LIBNAME LIBDB1_SO
#else
# define LIBNAME LIBDB_SO
#endif
> - scripts/test-installation.pl will fail.
I don't know the reason why this should fail but it is certainly
correctable.
> Are there any chances to fix all of this problems ? Or should I
> generate separate packages for glibc 2.0 binary compatibility and not
> add-ons ?
I would love to have an add-on. If this is too difficult we could
live without this, though.
I think we should investigate the possibility to avoid using the rules
for building the library objects and instead write own versions in the
db/Makefile. This should solve the problems.
-- Uli
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------