[1617] in Kerberos_V5_Development
Re: Where do we stand on libkdb and shared libraries?
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Aug 19 18:21:09 1996
To: epeisach@MIT.EDU
Cc: tlyu@MIT.EDU, krbcore@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 19 Aug 1996 18:20:49 -0400
In-Reply-To: epeisach@MIT.EDU's message of Mon, 19 Aug 1996 15:00:02 -0400
>>>>> "epeisach" == epeisach <epeisach@MIT.EDU> writes:
epeisach> As I see it there may be several gotchas currently wrt
epeisach> shared libraries.
epeisach> a) In making a shared libkdb5 - do we need a shared
epeisach> libdb? Currently we are relying on the fact that the
epeisach> ndbm and db interface names are the same - so they are
epeisach> initially resolved - but is this healthy?
This is true on all platforms besides the Alpha and AIX. On
the Alpha it is mostly true, with the exception of any symbols in
libkdb5 that are not in libc, which are left unresolved. This is
unhealthy, but works on everything besides AIX.
epeisach> b) Under AIX - what happens if you specify that a shared
epeisach> kdb5 depends on a static db - will you get a valid
epeisach> library? Or will you suck in all the objects from the
epeisach> static library?
AIX has tightly bound shared libraries. This means that a
symbol in an AIX shared library is resolved to a specific section of
code as soon as possible, and this binding is never broken. If you
link libkdb5 without a static libdb.a, you will bind to the ndbm
symbols in libc.a, and you will actually call these symbols at run
time. I.E. you use ndbm for the principal database. This is bad. If
you bind to the static libdb.a, then you actually pull in the objects
into libkdb5, and bind to the db symbols there. However, these
symbols are not exported from libkdb5, so they do not conflict with an
application that also links against libdb.a. A result of this is
that the libdb code is bound into both libkadm5 and libkdb5. In
addition, if an application also used libdb, it would be linked
statically into that application. If libkdb5 calls a db routine, it
calls the version of the db routine bound into libkdb5; same for
libkadm5--it gets its own version of the routine. Actually, in terms
of providing a nice encapsulation model and preventing problems like
what we have under NetBSD, this works well. Unfortunately, it
duplicates code. This is bad, but it's better than using ndbm.
epeisach> c) Based on (a) and (b) do we need a shared libdb?
epeisach> Should kdb_dbm.c be rewritten to use libdb directly?
Eventually yes, and probably.
epeisach> Ezra
