sgidladd(3c)
sgidladd - Opens a shared object and adds its variables to the name space.
As shipped in IRIX 6.5.5. Added in IRIX 6.5.5.
NAME sgidladd - Opens a shared object and adds its variables to the name space. SYNOPSIS cc [flag ...] file ... -lc [library ...] #include <dlfcn.h> void *sgidladd(const char *pathname, int mode); IMPLEMENTATION IRIX systems DESCRIPTION sgidladd is a facility for dynamically loading shared objects. Unlike dlopen(3) (without RTLD_GLOBAL), the loaded shared object and all associated dependent shared objects are added to the list of shared objects just as if they had been specified at the time the program was linked, or as if the _RLD_LIST (see rld(1)) environment variable had been used. That is to say, all of the names in the shared object become available to satisfy references in shared objects during lazy text resolution. The DSOs are globally visible (see also the "Namespace Issues" section in the dlopen(3c) man page). mode can be any one of RTLD_LAZY, RTLD_NOW, or RTLD_NOW_REPORT_ERROR. RTLD_NOW mode does exactly the same thing as RTLD_LAZY. When the mode is specified as RTLD_LAZY or RTLD_NOW, resolution of all symbols is performed, so that references that were previously unbound or bound to weak symbols can be rebound to strong symbols. However, unresolvable function references (references to symbols that do not exist in any shared object or in the mainline) are left dangling for further "lazy" resolution, (possibly pending another call to sgidladd). When the mode is specified as RTLD_NOW_REPORT_ERROR, resolution of all symbols is performed, and any unresolvable reference results in an error return from sgidladd. In this case, because resolution was not completed, it is very dangerous to continue execution. The main use for this function is to ensure that at the point of sgidladd execution, all symbols have been resolved. This facility is useful for verifying completeness of interfaces. As with dlopen, a handle to the added object is returned. This handle can be used to obtain addresses of specific symbols within the added object. This is somewhat less useful than with dlopen (without RTLD_GLOBAL), since in the case of sgidladd, rld can resolve these symbols directly (as can dlopen with RTLD_GLOBAL). sgidladd is available in a library that is loaded if the -lc option is used with cc, f77, or ld. Searching for Shared Objects If other shared objects were link edited with pathname when pathname was built, dlopen automatically loads those objects. The directory search path used to find both pathname and the other needed objects is the same as that used by rld(1). In particular, the search for pathname occurs in the following locations in the following order: 1. The directory that pathname specified if it is not a simple file name (that is, it contains a / character). In this case, the exact file is the only location searched; steps two through four are ignored. 2. Any path specified by the -rpath argument to ld(1) when the executable file was statically linked. 3. Any directory specified by the LD_LIBRARY_PATH environment variable. This environment variable should contain a colon- separated list of directories, in the same format as the PATH variable (see sh(1)). 64-bit programs examine the LD_LIBRARY64_PATH variable, and if it is not set, they examine LD_LIBRARY_PATH. New 32-bit ABI programs examine the LD_LIBRARYN32_PATH variable, and if it is not set, they examine LD_LIBRARY_PATH to determine whether an ABI-specific path has been specified. All three of these variables are ignored if the process is running setuid or setgid (see exec(2)). 4. The default search paths are used. These are /usr/lib:/lib for 32-bit programs, /usr/lib64:/lib64 for 64-bit programs, and /usr/lib32:/lib32 for new 32-bit ABI programs. The _RLD_ROOT variable has its usual effect, as documented in the manpage for rld(1) (which means that for a setuid or setgid program, _RLD_ROOT is ignored). You can use sgidladd to open any number of times objects whose names resolve to the same absolute or relative path name. However, the referenced object is loaded only once into the address space of the current process. The same object referenced by two different path names, however, can be loaded multiple times. For example, given the object /usr/home/me/mylibs/mylib.so, and assuming the current working directory is /usr/home/me/workdir, the following code results in mylib.so being loaded twice for the current process: ... void *handle1; void *handle2; handle1 = sgidladd("../mylibs/mylib.so", RTLD_LAZY); handle2 = sgidladd("/usr/home/me/mylibs/mylib.so", RTLD_LAZY); ... On the other hand, given the same object and current working directory, if you set LD_LIBRARY_PATH equal to /usr/home/me/mylibs, the following code results in mylib.so being loaded only once. ... void *handle1; void *handle2; handle1 = sgidladd("mylib.so", RTLD_LAZY); handle2 = sgidladd("/usr/home/me/mylibs/mylib.so", RTLD_LAZY); ... NOTES Use of dlclose on a DSO that has been added through use of sgidladd can cause surprising side effects because dlclose forces many symbol's GOT entries to be reset for re-lazy-evaluation. A result of this is that previously-saved (by the application or some library) function pointers might hold values that could be obsolete or no longer correct. Symbol lookups proceed in order on a linear list, and a DSO is not opened twice with the same version number (unless different dlopen paths make the DSO name appear different to rld). When multiple sgidladd commands are executed and an earlier DSO is closed by dlclose, this can change the symbol to which a call is resolved. For more information, see the "Namespace Issues" section in the dlopen(3c) man page. RETURN VALUES If pathname cannot be found, cannot be opened for reading, or is not a shared object, or if an error occurs during the process of loading pathname or relocating its symbolic references, sgidladd returns NULL. More detailed diagnostic information is available through the dlerror(3c) man page. SEE ALSO dlopen(3) dlerror(3), dlclose(3), dlsym(3), sgidlopen_version(3), rld(1), dso(5) This man page is available only online.