On Wed, Mar 01, 2000 at 10:05:27AM -0800, Jason Thorpe wrote:
> On Wed, 01 Mar 2000 22:26:51 +0900 
>  "T.SHIOZAKI" <tshiozak@astec.co.jp> 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?

Quick question:

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
functions.

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