neff@bellahs.UUCP (Dan Neff) (02/28/91)
Please respond to this article in the appropriate news group. Our e-mail has been bouncing mail lately and I don't want to miss any of your valuable responses. 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. For those not familiar with VMS, shareable images allow you to call a routine that you haven't actually linked into your executable. The above library call returns a pointer to the routine you request that you can then execute. This is especially nice for product installation where sites may have site-specific interfaces that share the same calling parameters, and by just looking at a logical or environment variable you can determine the site specific routine to call. This does away with having a separate executable for each site. Any experience or tips you could share about dynamic binding or shareable images in the Unix environment would be greatly appreciated! Thanks in advance. -- = Dan Neff Bell Atlantic Healthcare Systems = = Phone: (415) 925-0121 Greenbrae, CA. = = = = E-mail: uunet!bellahs!neff uunet!neff@bellahs.UUCP =
kpt@ibism.UUCP (Kevin Tyson) (03/01/91)
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 <dlfcn.h> 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
sethr@cbnewsl.att.com (seth.r.rosenthal) (03/02/91)
In article <598@bellahs.UUCP>, neff@bellahs.UUCP (Dan Neff) writes: > Please respond to this article in the appropriate news group. Our > e-mail has been bouncing mail lately and I don't want to miss > any of your valuable responses. > > 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. I won't comment on comparability to VMS, but UNIX System V Release 4 has dynamically linked shared libraries. A good place to find information about the facility, and how it ties into the Elf object format is the SVR4 Generic ABI, available from Prentice-Hall. Any of the processor supplements will explain some of the architecture dependant details for various platforms. Seth Rosenthal
guy@auspex.auspex.com (Guy Harris) (03/02/91)
>The same funcationality is avaiable in most implementations of unix. Well, not exactly. Various people have whipped up packages that sit *atop* most implementations of UNIX to provide this, but most implementations (implementations, not machines shipped with the implementations) don't have it yet. The ones that do, or will, include: SunOS 4.1 and later, and System V Release 4 (the latter has a mechanism basically the same as the former in its API); OSF/1; AIX 3.x; the NeXT version of Mach, I think; possibly other versions of Mach. Previous releases of S5 from AT&T didn't have it (yes, S5R3 had shared libraries, but *not* any built-in ability to link in stuff *during* the execution of a program), and no current BSD releases have it, for example. >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. It had an *extremely* severe problem in releases prior to 4.1, which rendered it completely unusable; the problem is called "nonexistence". It didn't show up until 4.1; there may have been some bugs in 4.1's version that were fixed in 4.1.1 (there's one bug in 4.1's version that *didn't* get fixed, alas, namely that the run-time loader can get confused and think "/dev/zero" is still open from when it first loaded the shared libraries for the program).
guy@auspex.auspex.com (Guy Harris) (03/03/91)
>I won't comment on comparability to VMS, but UNIX System V Release 4 >has dynamically linked shared libraries. *And* a procedural interface to the dynamic linker, which is what the original poster appeared to be asking about (SunOS 4.0[.x] has dynamically-linked shared libraries, but no procedural interface to the linker - the interface first appeared in 4.1). >A good place to find information about the facility, and how it ties >into the Elf object format Although one of the reasons run-time dynamic linking built into the OS (NOTE: *NOT* necessarily built into the kernel - it's all done in user mode, atop "mmap()", in SunOS 4.x and S5R4) is a win is that you can do run-time dynamic linking without having to *know* about the object file format; i.e., you don't have to write your own dynamic linking code that groks object files.