Recent Posts by Rod Evans

Every now and then, someone encounters the following error. % cc -G -o foo.so foo.o -lbar ld: fatal: file foo.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to foo Or perhaps the similar error. % cc -G -xarch=amd64 -o foo.so foo.o -lbar ld: fatal: file foo.o: wrong ELF class: ELFCLASS32 ld: fatal: File processing errors. No output written to foo This issue stems from the compiler flags that have been used to compile the...

Recently, a customers use of C++ objects within a dlopen(3c) environment revealed a problem that took some time to evaluate and understand. Sadly, this seems to be a recurring issue where the expectations of the C++ implementation are compromised by dynamic linking capabilities. Of course, dynamic linking is the norm for Solaris, and C++ is commonly employed in dynamic linking environments. But there are subtleties in regards symbol visibility that can cause problems. This...

I recently came across a mail exchange where the following runtime linker error message was observed: illegal mode: potential multiple path expansion requires RTLD_FIRST The exchange, and a quick review of the documents, reveal that some explanation wouldn't go amiss. The runtime linker, ld.so.1, provides a number of tokens that can be used within dynamic linking string definitions. These string definitions can provide filters, dependencies and runpath information, and are...

A customer recently posted to the Dynamic Linking forum in regards to an awfully slow link-edit. A shared library, built from Sun Studio 10 with debugging (-g), was taking 20 minutes to link on Solaris. By comparison, the same link took 4-5 minutes on Linux, and 15 seconds on Windows. I got a copy of the objects and found that the link-edit was considerably faster on my desktop - less than a minute. This is no small link-edit. There are a number of very large input files,...

Recently we had to make yet another modification to our runtime .init processing to compensate for an undesirable application interaction. I thought an overview of our torturous history of .init processing might be entertaining. During the creation of a dynamic object, the link-editor ld(1), arranges for any .init and .fini sections to be collected into blocks of code that are executed by the runtime linker ld.so.1(1). These blocks of code are typically used to implement...

In a previous post, I'd explained how lazy loading provides a fall back mechanism. If a symbol search exhausts all presently loaded objects, any pending lazy loaded objects are processed to determine whether the required symbol can be found. This fall back is required as many dynamic objects exist that do not define all their dependencies. These objects have (probably unknowingly) become reliant on other dynamic objects making available the dependencies they need. Dynamic...

Welcome to OpenSolaris. I've been working with the link-editors for many years, and I thought that with the general availability of the source, now would be an opportune time to cover some history, and give a brief overview of the link-editors source hierarchy. The link-editor components reside under the usr/src/cmd/sgs directory. This Software Generation Subsystem hierarchy originated from the AT&T and Sun collaboration that produced Solaris 2.0. Under this directory exist...

A recent customer observation reminded me of a subtlety of shared object dependency lookup, and a change that occurred between Solaris 8 and 9. The customer observed different dependencies being loaded on the two systems, although the applications file system hierarchy was the same on the two systems. On Solaris 8, the following was observed. $ ldd ./app libX.so.1 => /opt/ISV/weblib/libX.so.1 libY.so.1 => /opt/ISV/weblib/libY.so.1 libZ.so.1 => ...

A couple of folks have come across the following relocation error when running their applications on AMD64: $ prog ld.so.1: prog: fatal: relocation error: R_AMD64_32: file \\ libfoo.so.1: symbol (unknown): value 0xfffffd7fff0cd457 does not fit The culprit, libfoo.so.1 has been built using position dependent code (often referred to as non-pic). Shared objects are typically built using position independent code, using compiler options such as -Kpic. This...