[1623] in Kerberos_V5_Development
Re: Where do we stand on libkdb and shared libraries?
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Aug 20 13:16:02 1996
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, tlyu@MIT.EDU, krbcore@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 20 Aug 1996 13:15:54 -0400
In-Reply-To: Ezra Peisach's message of Mon, 19 Aug 1996 21:47:29 EDT
>>>>> "Ezra" == Ezra Peisach <epeisach@MIT.EDU> writes:
Ezra> So the issues as I see it then fall into the following
Ezra> If you do not specify -ldb - you will have the potential of
Ezra> getting unresolved symbols - fatal on at least the Alpha.
Ezra> Also, under AIX - you would then bind explictly to the C
Ezra> library version of ndbm (assuming I understand this
Ezra> correctly).
You can tell the Alpha linker to expect unresolved symbols. However, you may not get them, as you may find ndbm interfaces in libc. It will work out and get the right symbols at run time.
AIX is the only platform I know of that can't be made to deal
with unresolved symbols in a manner that works for us. (It has a
concept of unresolved symbols, but it would require more hacking on
libdb2 to get it to generate symbols that could bind to the unresolved
symbols than it would to get it to be shared.)
Ezra> Therefore - we lose with and without -ldb.
Although we can semi-win with a combination that is platform
dependent. Still, this is sub-optimal.
Ezra> b) Problems with making libdb shared... Name conflict for
Ezra> systems which already have libdb - should we call it libdb2?
Ezra> c) Another option - merge the objects into the libkdb -
Ezra> similar to how the profile library is merged with libkrb5.
Ezra> Advantage of this approach - developers will always get the
Ezra> right libdb version.
Remember that this isn't as simple as it looks because of the PIC code issue on some platforms (ix86). It might require some hacking of the db2 build process just to generate PIC code.
--Sam
