Bug 21659

Summary: Berkeley db library is statically compiled into libc, which make use of newer BDB very difficult, if possible at all
Product: Base System Reporter: matrix <matrix>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description matrix 2000-09-30 11:10:01 UTC
FreeBSD has Berkeley DB package statically linked into libc. The db version is 1.85. When, for example, perls DB_File is installed it is linked against libc (complaining that libdb is not found) and therefore uses Bdb 1.85, which is very old. AFter installing a newer BDB (say, 2.7.7 from the ports) DB_FIle still links against the old db lib and everything in the system is using the old db library. This make very difficult (or impossible) to exchnage db file with other oses which use Berkeley DB of newer version.

Fix: 

Stop statically linking libdb into libc. Make a separate libdb library, so user can easily upgrade berkeley db library when newer releases are available.
How-To-Repeat: Create a db file with a newer Berkely DB library where it is possible to do so. Try to read it in FBSD. Install BDB 2.7.7 from the prost, recompile DB_File and try to access it via perl script. Not luck.
Comment 1 Garrett A. Wollman 2000-10-03 18:50:11 UTC
<<On Sat, 30 Sep 2000 03:07:02 -0700 (PDT), matrix@ipform.ru said:

> Stop statically linking libdb into libc. Make a separate libdb
> library, so user can easily upgrade berkeley db library when newer
> releases are available.

Impractical.

Several important libc functions depend on having databases
available.  Something which exports an ndbm-compatible interface is
required by SUSv3/POSIX.1-200x.  The on-disk file formats are in any
case incompatible between db 1.x and db y.x for all y > 1.

-GAWollman
Comment 2 ashp freebsd_committer freebsd_triage 2002-02-09 18:54:29 UTC
State Changed
From-To: open->suspended

As explained, this is such a large change that I cannot see it 
ever happening (or at least, anytime soon.)  Suspend this for 
now.
Comment 3 xfb52 2002-07-05 17:45:14 UTC
FreeBSD-4.4-RELEASE.

If anything has materially changed since 4.4 then please advise me (I
found nothing in the release notes).


Surely it is possible to both have BDB 1.85 in libc, use 1.85 for
library function and *still* allow newer versions to be installed an
used successfully.

Background: libc contains Berekeley DB 1.85 routines and these are used
by some library functions (e.g. getpwent and friends).  You can install
a newer version of Berekeley DB (e.g. 2.7.7) as libdb2 and link
applications against it, but if that application also links against libc
(pretty likely) *and* uses any libc routine which expects BDB 1.85 then
you are in trouble.  An obvious example of such an application is Perl. 
A version of Perl which links against libdb2 cannot do any getpwent (and
related) system calls because the file format of /etc/pwd.db is
incompatible with BDB versions other than  1.85 and the library
functions pick up dbmopen etc. from libdb2.


However, there is no need for the *libc* routines which use BDB to use
the standard function names.  A parallel version of 1.85 with function
names changed in some standard way (say by prefixing k_, or appending
_185) could be used by the library functions themselves.  The standard
dbmopen etc. can stay in libc because they can easily be overridden by
linking against a newer BDB library.

It's not pretty, but I don't believe it's as impractical as the original
reply stated.

--Alex

-- 
Email: xfb52@dial.pipex.com
Comment 4 Edwin Groothuis freebsd_committer freebsd_triage 2008-08-07 03:27:39 UTC
State Changed
From-To: suspended->closed

This is properly managed via the dbd-ports in the ports collection 
which all have their own name.