From owner-freebsd-questions Wed Jul 30 02:13:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA20934 for questions-outgoing; Wed, 30 Jul 1997 02:13:32 -0700 (PDT) Received: from forwiss.tu-muenchen.de (root@forwiss.tu-muenchen.de [131.159.128.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA20916 for ; Wed, 30 Jul 1997 02:13:22 -0700 (PDT) Received: from pccog4.forwiss.tu-muenchen.de (hafner@pccog4.forwiss.tu-muenchen.de [131.159.128.55]) by forwiss.tu-muenchen.de (8.8.5/V5) with ESMTP id LAA12819; Wed, 30 Jul 1997 11:13:18 +0200 (MET DST) Received: (hafner@localhost) by pccog4.forwiss.tu-muenchen.de (8.8.5/8.6.12) id JAA01180; Wed, 30 Jul 1997 09:15:04 GMT Newsgroups: comp.unix.bsd.freebsd.misc To: freebsd-questions@FreeBSD.ORG, hafner@forwiss.tu-muenchen.de Subject: questions about dlopen() From: Walter Hafner Date: 30 Jul 1997 11:15:01 +0200 Message-ID: Lines: 79 X-Newsreader: Gnus v5.2.25/XEmacs 19.14 Posted-To: comp.unix.bsd.freebsd.misc Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following message is a courtesy copy of an article that has been posted as well. Hi there! I've got a few questions regarding the 'dlopen()' call. I had a look at the sources (/usr/src/lib), but didn't find any references to dlopen(). The manpage is no help either. Problem: We try to read shared libs into an application at runtime. Our application supports various framegrabbers on various hardware (HP, Sun, SGI, PC/Linux, PC/FreeBSD ...) and we have to load wrapper-libs that provide a consistent user interface at runtime (plus the vendor-specific libs of course). That's where 'dlopen()' comes in handy. The following code snipplet works on _all_ hard- and software combinations _except_ FreeBSD 2.2.* (didn't try 2.1.*): #define RTLD_LAZY 1 [...] hndl = dlopen(name,RTLD_LAZY); if (hndl == NULL) return H_ERR_DLOPEN; On all platforms except FreeBSD, dlopen() searches LD_LIBRARY_PATH for the library and returns successfully. On FreeBSD, I get a NULL pointer. If I query dlerror(), I get a "2 ENOENT No such file or directory". dlopen() finds the library only if I cd into the lib-Directory. If it's a ldconfig problem: I can't use ldconfig, because the wrapper libs are named after the corresponding framegrabbers. In the current case: Meteor.so. Ldconfig only looks for files named libXXX.so.XXX. So what's the deal? If a filename is passed to dlopen(), dlopen() seems to look only in the exact path the filename specifies. And if a name without directory information is passed, only the current directory is searched. I find this behaviour very frustrating. Compare the Solaris manpage to dlopen(): A path name containing an embedded '/' is interpreted as an absolute path or relative to the current directory, otherwise the set of search paths currently in effect by the run-time linker will be used to locate the specified file Linux is similar: If filename is not an absolute path (i.e., it does not begin with a "/"), then the file is searched for in the following locations: A colon-separated list of directories in the user's LD_ELF_LIBRARY path environment variable. If and only if LD_ELF_LIBRARY_PATH is not defined, LD_LIBRARY_PATH is used in its place. The FreeBSD manpage gives no informations on the search path. As I said: FreeBSD seems to be the only system that handles dlopen() arguments that way. Or _does_ the FreeBSD dlopen() search the library path, but looks only for lib*.so like ldconfig does? Is there any convenient way to circumvent these problems? Currently I use a getenv("LD_LIBRARY_PATH"); call and then fiddle with the result to provide dlopen() with all the paths to look in. Is this _really_ the only solution? Thanks, -Walter PS: The date of dlopen(3) is "24 September 1989" ... maybe time for an update? -- Walter Hafner_____________________________ hafner@forwiss.tu-muenchen.de *CLICK* The best observation I can make is that the BSD Daemon logo is _much_ cooler than that Penguin :-) (Donald Whiteside)