From owner-freebsd-hackers Fri Feb 19 17: 1:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 727CF118AA for ; Fri, 19 Feb 1999 17:01:50 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA20670; Fri, 19 Feb 1999 18:01:44 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd020553; Fri Feb 19 18:01:34 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA16228; Fri, 19 Feb 1999 18:01:23 -0700 (MST) From: Terry Lambert Message-Id: <199902200101.SAA16228@usr02.primenet.com> Subject: Fixing dlopen, ld.so, and upgrading the resolver To: bright@cygnus.rush.net (Alfred Perlstein) Date: Sat, 20 Feb 1999 01:01:23 +0000 (GMT) Cc: gurudatt@cs.tamu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Alfred Perlstein" at Feb 18, 99 08:41:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What libraries does one include to compile socket programs in freebsd? > > > solaris?> > > They are mostly part of libc and therefor linked in by default. Basically > you do not need these libs. -lsocket is a lame SRV4 (i think) thing because > BSD sockets are simulated (poorly) via userland code. > > If you get any unresolved symbols check the function's manpage, or > us 'nm' on the libraries in /usr/lib to locate it. On the other hand, the -lnsl has been changed to -lresolve, and is standard on most platforms. The lack of this library in FreeBSD is caused by the resolver code being integrated into libc. It is probably time for this to change. It can still be *virtually* in libc in ELF by linking libc.so against libresolve.so (though I find this approach to be *highly* undesirable, since it means that things that link dynamically will need a different command line to link statically (e.g.: another library argument). By the same token, it's about time for an nsswitch, so that things like getpwent can be backed by password files or databases, for purposes other than authentication (e.g. PAM is useless for getting GECOS data out of an LDAP directory). PAM and an nsswitch imply a need for statically linked objects to be able to access dlopen and friends (or an end to static linking). SVR4 handles this with a libdlopen, and the execution class loader premaps the ld.so into all images. The library stub is basically jump table data for the premapped ld.so. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message