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

[Peter Keller]

On Mon, May 14, 2007 at 11:55:31AM -0400, Brandon Van Every wrote:
> Any static linking horror stories out there?

Sure, I have some that aren't necessarily apple related, but could
happen on that platform. Although, it isn't so much of static linking as
static/dynamic linking. You need both sides of that coin.  These problems
generally arise when distributing binaries between machines but often
how up across revisions of the same OS--like RHEL3 to RHEL5.

Example 1
---------

1. You statically link the openssl libraries into your application because
you can't guarantee that the target platform will have one. So, you move
your executable to a machine, start it up, and here is what could happen

2. The program loads the executable, the initializers are run, now some global
memory space is initialized for openssl. 

3. The program decides to call getpwnam() later, which the administrator
happens to have configured to use LDAP with an SSL backend.

4. The lazy load of the ldap resolver, which then brings in the ssl
library cause the dynamic ssl library initialization routines to be
run again.  If the two version of the libraries were the same, then
depending when this happens there might be no effect. If they are
different versions, either of the two ssl libraries will get confused
and probably segfault.

5. This is because the global variable space for both the static version
of the library and the dynamic version (probably) resolve to the same
symbol names, so they get trashed in the process space.

Example 2
---------

1. Supppose you're on linux and you have an older .a library like say fftw
that you compiled a while ago.

2. The glibc maintainers change _IO_STDIN to __IO_STDIN in the header files,
unfortunately, this happens to be a realized object in the header files and
requires space when compiling.

3. You now try to statically link your older library against your
executable and get an unresolved symbol for _IO_STDIN. 

4. This problem actually exists for the dynamic versions as well, but the
dynamic linker knows to "fix it up" duing link load time. This does not
happen with static linking. 

5. It is a problem when you are a sysadin for a large facility and now have
hundreds of libraries to recompile against the newer versions of glibc
headers.

Example 3
---------

1. You compile your C++ libraries with gcc 3.2.x. It uses all manner of 
templates and exceptions and other runtime C++ goo.

2. Later, you link those libraries against a project compiled on a machine
with gcc 4.1.x. You don't necessarily even have to have a C++ API,
it could be wrapped with C.

3. What will happen is that depending on the C++ feature set you chose, 
one of three things will happen:
        1. The program fails to link due to the expected runtime/STL interfaces
                of the C++ features you want don't exist in the current 
libstdc++
                libraries.
        2. The program immediately fails during global constructor 
initialization.
        3. The program runs happily until you throw an exception and then it
                segfaults due to missing/incorrect semantic initialization 
between
                the execption system in the older library execption ABI and the 
                newer libstdc++.


I have some others I've discovered over the years, but the above routinely
cause me trouble.

-pete