Subject: Re: dl* functions on ELF platforms
To: Jason Thorpe <firstname.lastname@example.org>
From: Kevin P. Neal <email@example.com>
Date: 03/01/2000 20:30:29
On Wed, Mar 01, 2000 at 10:05:27AM -0800, Jason Thorpe wrote:
> On Wed, 01 Mar 2000 22:26:51 +0900
> "T.SHIOZAKI" <firstname.lastname@example.org> wrote:
> > There is probably not much difference whether provide libdl or not.
> > However, I don't prefer to increase the number of libraries, since
> > it may make maching problem. If libc depends on libdl, it seems not
> > necessary to separate into libdl. And, I guess that if we provide libdl,
> > then we should change the soname and/or the major revision number of libc.
> Well, I'm buy your argument that they should be in libc.
> Anyone have any real objections?
Would these functions be available in both the static and dynamic
versions of libc?
Here's my issue (and perhaps it doesn't apply here):
At my job I'm responsible for the Apache builds (+mod_ssl,+perl, +custom
afs client code, etc etc). I like to do the builds static because it makes
lots of things easier (on HP-UX: debugging, debugging, more debugging,
and the usual benefits of static linking. Solaris also).
I'm annoyed that I can't get a totally static build because of dl*
functions in some library (I can't remember offhand, and I link in
something like 20 libraries...). I have to pull schenanegans to
get my servers to build with this motley list of libraries, giving
flags to cut static/dynamic linking on/off, in order to get a build.
I mean, really now, should this be in a build:
-lc -lBSD -Wl,dynamic -lc -Wl,static
That's gross. (libBSD on HP-UX pulls in compat functions needed by AFS,
but I have to link libc in first so things like stat() aren't subverted.)
I hate it when static and dynamic versions of libraries have different
I hope this sort of thing won't be an issue in NetBSD.
Kevin P. Neal http://www.pobox.com/~kpn/
"Nonbelievers found it difficult to defend their position in \
the presense of a working computer." -- a DEC Jensen paper