Re: [Chicken-users] Mac OS X static library names

[Peter Keller]

On Mon, May 14, 2007 at 04:39:15PM -0400, Brandon Van Every wrote:
> But, I've never observed dynamic linking complications in
> all the time that CMake has been tested.  Peter Keller's post also seems to
> indicate that static linking is the case more likely to cause problems.

In general, an easy way to observe pure dynamic linking troubles is like this:

Often times, NSS resolvers are implemented via a manual dlopen() in libc.
So, especially on linux, create a dynamically linked executable, move the
binary to another machine, and if the OS (specifically glibc) releases
are "far enough" apart, then the executable will probably segfault when
calling getpwnam().

Here is an example on my linux machine:
Linux black > ldd /lib/libnss_wins.so.2
        linux-gate.so.1 =>  (0xb7f10000)
        libldap-2.2.so.7 => /usr/lib/libldap-2.2.so.7 (0xb7dff000)
        liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xb7df3000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7ddf000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7d7a000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7d59000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7d56000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb7d41000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7c16000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7c02000)
        libssl.so.4 => /lib/libssl.so.4 (0xb7bce000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0xb7ae5000)
        /lib/ld-linux.so.2 (0x004d0000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ae0000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7ab2000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7aa2000)

If I were to release a package that dynamically linked with sasl2, krb5,
or gssapi, I'd probably run into problems if someone wanted to use this
resolver type. It would be because I'd be providing a dynamically linked
krb5 library for my application because I needed some alpha copy of krb5
which fixed a bunch of bugs. The two libraries would clash and boom.

***

If the intention is that binary distribution simply never happens and
the source is always recompiled for the target machine, then this stuff
mostly goes away (except for this example, which is a more serious
semantic problem with dynamic libraries as a whole).

Dynamic libraries were created to solve upgradability and text size in the
VM problems. However, they do have some nasty edge cases. Truth be told,
you probably won't hit any of them unless you A) want multiple revisions
of a tool coeexisting on the same machine or B) write an application
which does heavy systems programming at the kernel->library layer and
release binaries only.

So, the summary of my argument is that out of all linking problems, both
static and dynamic, 80% of them would be related to static linking, 20%
of them would be related to dynamic linking. This is purely anecdotal
from my previous experiences on this issue.

Either way, they are usually very difficult to fix when they do happen.

Later,
-pete