Recent Posts by Rod Evans

Frequently it is desirable to compare two ELF files. As someone who makes changes to the link-editor, comparing large numbers of built objects is a vital part of verifying any changes. In addition, determining what objects have changed from one build to another, can reduce object distribution to only those objects that have changed. Often, it is simply enlightening to know "what did I change in this ELF file to make it different?". Various tools exist to compare ELF files,...

In a previous posting I covered the use of filters, especially defining symbol specific filtering. Filters allows the redirection of a binding at runtime to an alternative filtee. This technique has been used to provide optimized, platform specific, instances of functions. For example, libc.so.1 has provided a number of platform specific filtees, libc_psr.so.1, that provide optimized versions of the memmove() family. ldd(1) reveals these filtees. % ldd /bin/date ...

In a previous posting I introduced the use of direct bindings within the OSNet consolidation. A comment to this posting questioned the difference between the -z direct and -B direct options, and pointed out that runtime errors can occur during process execution if a lazy dependency (typically enabled with -B direct) can not be found. In this entry, I discuss the difference between the -z direct and -B direct options, and offer a useful technique for handling the case where...

Direct Binding refers to a symbol search and binding model that has been available in Solaris for quite some time. Library Bindings. At runtime, a symbol reference from an object must be located by the runtime linker, ld.so.1(1). Under direct bindings, symbol definitions are searched for directly in the dependency that provides the symbol definition. The provider of the symbol definition was determined by the link-editor, ld(1) when the object was originally built. This direct...

A recent update to Solaris Nevada (build 68 to be precise) has moved the /usr/ccs/bin utilities to /usr/bin. This move includes the link-editor, and associated utilities.

A recently added error check within ld(1) has uncovered the following condition. ld: warning: symbol `_init' not found, but .init section exists - \\ possible link-edit without using the compiler driver ld: warning: symbol `_fini' not found, but .fini section exists - \\ possible link-edit without using the compiler driver The encapsulation, and execution of .init and .fini sections is a combination of user definitions and compiler driver files. Users typically create...

There have been a couple postings recently regarding relocation warnings that have been observed when using the link-editors -z verbose option. The first warning originates from building a shared object: ld: warning: relocation warning: R_SPARC_DISP32: file shared.o: \ symbol <unknown>: displacement relocation applied to the \ symbol __RTTI__1nEBase_: at 0x8: displacement relocation will \ not be visible in output image Then, if this shared object is referenced...

After reading a previous posting on versioning, a developer asked how they could specify what version to bind to when they built their application. For example, from the version definitions within libelf.so.1: % pvs -d /lib/libelf.so.1 libelf.so.1; SUNW_1.5; SUNW_1.4; .... SUNWprivate_1.1; how could you restrict an application to only use the interfaces defined by SUNW_1.4. Note, version SUNW_1.4 inherits previous versions. The...

A developer who wished to add /usr/sfw/lib to their default runtime search path, managed to turn their system into a brick by using crle(1): # crle -l /usr/sfw/lib # ls ld.so.1: ls: fatal: libsec.so.1: open failed: No such file or directory Killed The problem was that crle(1), in this basic form, created a system wide configuration file. This configuration file defined that the default runtime search path for shared object dependencies is /usr/sfw/lib. This...