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 _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users