Aix Shared Libraries And Lazy Loading
Callable shared objects (CSO), self-contained callable shared objects (scCSO), COBOL shared libraries, shared libraries are all examples of what UNIX thinks of as shared objects. There is no architectural difference between a shared object and shared library. There are simply different conventions about their naming and use. Most third party code, for example Oracle, is supplied as one or more shared objects.
Aix Shared Libraries And Lazy Loading
Partial executables, shared objects listed in the LD_PRELOAD environment variable, and their direct and indirect dependencies use lazy binding by default, except on AIX. Linker options and environment variables can change this. Shared objects loaded through COBOL by set proc-ptr to entry use immediate binding. Shared objects loaded using the C API dlopen() specify the binding mode to use as part of the call.
Lazy binding and lazy loading are different, though some sources use the terms interchangeably. Lazy loading is often used in conjunction with lazy binding. A lazily loaded dependency is not loaded when its parent is loaded. Loading is deferred until a symbol it defines is referenced.
In brief - setuid executables by default do not use the shared library search path environment variable. As COBOL executables need to locate the runtime in $COBDIR/lib this makes setuid COBOL executables problematic. In particular, if the COBDIR used when to link the application is not in the same place as the COBDIR used at runtime then the COBOL libraries will not be found. Possible solutions are to link the COBOL shared libraries into the default search directories, to add $COBDIR/lib to the default list of directories to search, or to add $COBDIR/lib to the list of trusted directories. All of these require admin level, typically root permission. Specification of default directory and trusted directory is very platform specific. See the links in Further Reading.
dlopen() allows one to specify the visibility of symbols in the newly loaded shared object, how the shared object searches to resolves any undefined symbols, and whether to use immediate or lazy binding.
The ld command can relink a program without requiring that you list all input object files again. For example, if one object file from a large program has changed, you can relink the program by listing the new object file and the old program on the command line, along with any shared libraries required by the program. See Example 3.
Ordinarily, a shared object used as input is only listed in the loader section of the output file if a symbol in the shared object is actually referenced. When the run-time linker is used, however, you may want shared objects to be listed even if there are no symbols referenced. When the -brtl option is used, all shared objects listed on the command-line that are not archive members are listed in the output file. The system loader loads all such shared objects when the program runs, and the symbols exported by these shared objects may be used by the run-time linker. Shared objects that are archive members are not loaded automatically unless automatic loading is enabled by an import file in the archive. To enable automatic loading, see Import and Export File Format.
When a module is linked, a list of its dependent modules is saved in the module's loader section. The system loader automatically loads the dependent modules once the module is loaded. When lazy loading is enabled, loading is deferred for some dependents until a function is called in the module for the first time.
A shared object contained in an archive is only listed if the archive specifies automatic loading for the shared object member. You specify automatic loading for an archive member foo.o by creating a file with the following lines:
For more information on creating a shared library, see "How to Create a Shared Library" in AIX General Programming Concepts: Writing and Debugging Programs. For more information on loading and binding, see the load subroutine in AIX Technical Reference: Base Operating System and Extensions Volume 1.
It would seem that libwav.so does not declare it's dependency on the library defining ODBCGeneralQuery. Try running ldd path-to-my-lib/libwav.so and see if there's something missing. If this is a shared library that you are building you should add -llibname to the linking command (the one that is something like gcc -shared -o libwav.so a.o b.o c.o) for each library that the library's code uses. Any other libraries referenced by the original shared library in this way should automatically be loaded as well.
In computing, a dynamic linker is the part of an operating system that loads and links the shared libraries needed by an executable when it is executed (at "run time"), by copying the content of libraries from persistent storage to RAM, filling jump tables and relocating pointers. The specific operating system and executable format determine how the dynamic linker functions and how it is implemented.
Linking is often referred to as a process that is performed when the executable is compiled, while a dynamic linker is a special part of an operating system that loads external shared libraries into a running process and then binds those shared libraries dynamically to the running process. This approach is also called dynamic linking or late linking.
In Unix-like systems that use ELF for executable images and dynamic libraries, such as Solaris, 64-bit versions of HP-UX, Linux, FreeBSD, NetBSD, OpenBSD, and DragonFly BSD, the path of the dynamic linker that should be used is embedded at link time into the .interp section of the executable's PT_INTERP segment. In those systems, dynamically loaded shared libraries can be identified by the filename suffix .so (shared object).
The dynamic linker can be influenced into modifying its behavior during either the program's execution or the program's linking, and the examples of this can be seen in the run-time linker manual pages for various Unix-like systems. A typical modification of this behavior is the use of LD_LIBRARY_PATH and LD_PRELOAD environment variables, which adjust the runtime linking process by searching for shared libraries at alternate locations and by forcibly loading and linking libraries that would otherwise not be, respectively. An example is zlibc, also known as uncompress.so,[a] which facilitates transparent decompression when used through the LD_PRELOAD hack; consequently, it is possible to read pre-compressed (gzipped) file data on BSD and Linux systems as if the files were not compressed, essentially allowing a user to add transparent compression to the underlying filesystem, although with some caveats. The mechanism is flexible, allowing trivial adaptation of the same code to perform additional or alternate processing of data during the file read, prior to the provision of said data to the user process that has requested it.
In the Apple Darwin operating system, and in the macOS and iOS operating systems built on top of it, the path of the dynamic linker that should be used is embedded at link time into one of the Mach-O load commands in the executable image. In those systems, dynamically loaded shared libraries can be identified either by the filename suffix .dylib or by their placement inside the bundle for a framework.
The dynamic linker not only links the target executable to the shared libraries but also places machine code functions at specific address points in memory that the target executable knows about at link time. When an executable wishes to interact with the dynamic linker, it simply executes the machine-specific call or jump instruction to one of those well-known address points. The executables on the macOS and iOS platforms often interact with the dynamic linker during the execution of the process; it is even known that an executable might interact with the dynamic linker, causing it to load more libraries and resolve more symbols, hours after it initially launches. The reason that a macOS or iOS program interacts with the dynamic linker so often is due both to Apple's Cocoa and Cocoa Touch APIs and Objective-C, the language in which they are implemented (see their main articles for more information).
The dynamic linker can be coerced into modifying some of its behavior; however, unlike other Unix-like operating systems, these modifications are hints that can be (and sometimes are) ignored by the dynamic linker. Examples of this can be seen in dyld's manual page. A typical modification of this behavior is the use of the DYLD_FRAMEWORK_PATH and DYLD_PRINT_LIBRARIES environment variables. The former of the previously-mentioned variables adjusts the executables' search path for the shared libraries, while the latter displays the names of the libraries as they are loaded and linked.
The dynamic linker can be influenced into modifying its behavior during either the program's execution or the program's linking.A typical modification of this behavior is the use of the LIBPATH environment variable.This variable adjusts the runtime linking process by searching for shared libraries at alternate locations and by forcibly loading and linking libraries that would otherwise not be, respectively.
Dynamic linking is generally slower (requires more CPU cycles) than linking during compilation time, as is the case for most processes executed at runtime. However, dynamic linking is often more space-efficient (on disk and in memory at runtime). When a library is linked statically, every process being run is linked with its own copy of the library functions being called upon. Therefore, if a library is called upon many times by different programs, the same functions in that library are duplicated in several places in the system's memory. Using shared, dynamic libraries means that, instead of linking each file to its own copy of a library at compilation time and potentially wasting memory space, only one copy of the library is ever stored in memory at a time, freeing up memory space to be used elsewhere. Additionally, in dynamic linking, a library is only loaded if it is actually being used.