Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!ibism!ibism.UUCP!kpt From: kpt@ibism.UUCP (Kevin Tyson) Newsgroups: comp.unix.internals Subject: Re: Shareable Images/dynamic binding possible with Unix? Keywords: vms Message-ID: <12293@ibism.uucp> Date: 28 Feb 91 21:06:36 GMT References: <598@bellahs.UUCP> Sender: news@ibism.uucp Reply-To: kpt@ibism.UUCP (Kevin Tyson) Organization: Citibank IBISM Lines: 152 In article <598@bellahs.UUCP>, neff@bellahs.UUCP (Dan Neff) writes: |> |> We would like to know if it is possible to have/implement shareable images |> in the Unix environment similar to the VMS implementation with |> the LIB$FIND_IMAGE_SYMBOL library call. I believe the same functionality |> exists in Unix with dynamic binding, but this is a difficult topic |> to find information on in the Unix environment. |> The same funcationality is avaiable in most implementations of unix. The one I am most familiar with is in the SunOS. Unlike VMS it is not packaged in a single call, however we have combined them into our own FIND_IMAGE_SYMBOL function. This has allowed us to provide identical funcationality with the VMS RTL. I've only used this under the current version of SunOS (4.1.1), but I've been told that it had problems in previous releases. The environment variable LD_LIBRARY_PATH play a role similar to logical names for shared images under VMS, particularly if you have used lib$find_image_symbol with privileged images. Here are the relevant manual pages: DLOPEN(3X) MISCELLANEOUS LIBRARY FUNCTIONS DLOPEN(3X) NAME dlopen, dlsym, dlerror, dlclose - simple programmatic inter- face to the dynamic linker SYNOPSIS #include void *dlopen(path, mode) char *path; int mode; void *dlsym(handle, symbol) void *handle; char *symbol; char *dlerror() int dlclose(handle); void *handle; DESCRIPTION These functions provide a simple programmatic interface to the services of the dynamic link-editor. Operations are provided to add a new shared object to an program's address space, obtain the address bindings of symbols defined by such objects, and to remove such objects when their use is no longer required. dlopen() provides access to the shared object in path, returning a descriptor that can be used for later references to the object in calls to dlsym() and dlclose(). If path was not in the address space prior to the call to dlopen(), then it will be placed in the address space, and if it defines a function with the name _init that function will be called by dlopen(). If, however, path has already been placed in the address space in a previous call to dlopen(), then it will not be added a second time, although a count of dlopen() operations on path will be maintained. mode is an integer containing flags describing options to be applied to the opening and loading process - it is reserved for future expansion and must always have the value 1. A null pointer supplied for path is interpreted as a reference to the "main" executable of the process. If dlopen() fails, it will return a null pointer. dlsym() returns the address binding of the symbol described in the null-terminated character string symbol as it occurs in the shared object identified by handle. The symbols exported by objects added to the address space by dlopen() can be accessed only through calls to dlsym(), such symbols do not supersede any definition of those symbols already present in the address space when the object is loaded, nor are they available to satisfy "normal" dynamic linking references. dlsym() returns a null pointer if the symbol Sun Release 4.1 Last change: 24 September 1989 1 DLOPEN(3X) MISCELLANEOUS LIBRARY FUNCTIONS DLOPEN(3X) can not be found. A null pointer supplied as the value of handle is interpreted as a reference to the executable from which the call to dlsym() is being made - thus a shared object can reference its own symbols. dlerror returns a null-terminated character string describ- ing the last error that occurred during a dlopen(), dlsym(), or dlclose(). If no such error has occurred, then dlerror() will return a null pointer. At each call to dlerror(), the "last error" indication will be reset, thus in the case of two calls to dlerror(), and where the second call follows the first immediately, the second call will always return a null pointer. dlclose() deletes a reference to the shared object refer- enced by handle. If the reference count drops to 0, then if the object referenced by handle defines a function _fini, that function will be called, the object removed from the address space, and handle destroyed. If dlclose() is suc- cessful, it will return a value of 0. A failing call to dlclose() will return a non-zero value. The object-intrinsic functions _init and _fini are called with no arguments and treated as though their types were void. These functions are obtained by specifying -ldl as an option to ld(1). SEE ALSO ld(1), link(5) Sun Release 4.1 Last change: 24 September 1989 2 -- Kevin P. Tyson Phone: 212-657-5928 Fax: 212-825-8607 IISA c/o Citibank E-Mail: uunet!ibism!kpt 111 Wall Street New York, NY 10043