Porting - 3. GNU libtool

GNU packages that build libraries use GNU libtool to hide platform-dependent procedures for library building and installation.

3.1 The Situation

In the wild, one can find four strands of libtool:

libtool 1.3: The most common strand. The last release from this branch is 1.3.5. It doesn't know about Darwin and only builds static libraries. It can be recognized by the presence of the files ltconfig and ltmain.sh in the source tree.
libtool 1.4: Long in the works and recently released as the new stable version, this branch has better autoconf integration. Unfortunately that makes migrating packages from 1.3 non-trivial. It supports Darwin 1.3 / Mac OS X 10.0 out of the box and needs a small patch to work on Mac OS X 10.1. It can be recognized by the absence of ltconfig. Versions that identify themselves as 1.3b or 1.3d are actually development snapshots of 1.4 and must be treated with caution.
The multi-language-branch: Also called MLB, this version of libtool was a parallel development branch that added support for C++ and Java (via gcj). It has now been merged back into the main development line. Recent versions support Darwin 1.3 and Mac OS X 10.0 out of the box. The MLB can be recognized by the files ltcf-c.sh, ltcf-cxx.sh and ltcf-gcj.sh.
The current development branch: This is the development version that will some day be released as libtool 1.5. It has resulted from the merge of 1.4 and the MLB. It supports C, C++ and Java (via gcj). Unfortunately, it can't be easily told apart from 1.4, you'll have to check the version number inside ltmain.sh.

In conclusion, libtool 1.3.x and packages that use it (which happens to be the majority of libtool-using packages out there) need a patch to build shared libraries on Darwin. Apple includes a patched version of libtool 1.3.5 in Mac OS X, but it will not work correctly in most cases. Christoph Pfisterer improved that patch to hardcode the correct path and to do full versioning. The changes were incorporated into upstream libtool releases and development versions starting with 1.4. Members of the Fink team continue to make improvements and forward them to the libtool maintainers. The versioning scheme is compatible across all libtool versions.

Side note: The libltdl library included with all libtool versions will only work on Darwin when dlcompat is installed. This is included with OS X starting with 10.3. For previous versions, one can install the fink "dlcompat" family of packages.

3.2 The 1.3.5 Patch

If you are building libtool 1.3.5 for yourself, you will need to apply this patch [updated 2002-06-09] to the libtool 1.3.5 source and then delete the files ltconfig and ltmain.sh. (They will be recreated from the appropriate .in files when you run configure and make.) This is done automatically, by the way, in the current Fink package for libtool 1.3.5.

But that's only half the work - every package using libtool comes with its own copies of ltconfig and ltmain.sh. So you must replace these in every package that you want to build as a shared library. Note that you must do this before running the configure script. For your convenience, you can get the two files right here: ltconfig (98K) and ltmain.sh (110K) [both updated 2002-06-09].

3.3 Fixing 1.4.x

There are at least three different versions of libtool 1.4.x now in wide use (1.4.1, 1.4.2, and later development snapshots). They all have some issues on Darwin, though the exact changes required to fix them differ. The "libtool14" package shipped via Fink has all required patches already applied to it. However, you still have to manually fix the ltmain.sh and configure files of affected packages in order to get them working.

The flat_namespace bug: This problem only occurs if you use libtool on Mac OS X10.1 and later. What happens is that libtool tries to use the -undefined suppress to allow undefined symbols, but doesn't specify along with it the -flat_namespace option. Starting with 10.1 this won't work anymore. A typical patch looks like this:

diff -Naur gdk-pixbuf-0.16.0.old/configure gdk-pixbuf-0.16.0.new/configure
--- gdk-pixbuf-0.16.0.old/configure	Wed Jan 23 10:11:48 2002
+++ gdk-pixbuf-0.16.0.new/configure	Thu Jan 31 03:19:54 2002
@@ -3334,7 +3334,7 @@
     ;;
 
   darwin* | rhapsody*)
-    allow_undefined_flag='-undefined suppress'
+    allow_undefined_flag='-flat_namespace -undefined suppress'
     # FIXME: Relying on posixy $() will cause problems for
     #        cross-compilation, but unfortunately the echo tests do not
     #        yet detect zsh echo's removal of \ escapes.

The loadable module bug: This bug is caused by the non-standard behaviour of zsh (which is the default shell in 10.0 and 10.1; starting in 10.2 bash is the default). Zsh's non-standard quoting behaviours prevents loadable module from being built correctly, they end up as shared libraries instead (unlike Linux, these are reall different things on Darwin). A typical fix for this (cut off, so you can't use it unmodified):

diff -Naur gnome-core-1.4.0.6.old/configure gnome-core-1.4.0.6.new/configure
--- gnome-core-1.4.0.6.old/configure	Sun Jan 27 08:19:48 2002
+++ gnome-core-1.4.0.6.new/configure	Fri Feb  8 01:10:21 2002
@@ -4020,7 +4020,7 @@
     # FIXME: Relying on posixy $() will cause problems for
     #        cross-compilation, but unfortunately the echo tests do not
     #        yet detect zsh echo's removal of \ escapes.
-    archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle || echo -dynamiclib) ...'
+    archive_cmds='$nonopt $(test x$module = xyes && echo -bundle || echo -dynamiclib) ...'
     # We need to add '_' to the symbols in $export_symbols first
     #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols'
     hardcode_direct=yes

This problem is fixed in some post-1.4.2 versions of libtool.

The convenience library bug: Under some conditions, libtool will fail to link convenience libraries, giving "multiple definitions" errors. This is caused by a more fundamental problem in libtool it seems. For now as a workaround (curing the symptoms not the actual problem, but with great success anyway), you can use this fix (thanks to Dave Vasilevsky):

--- ltmain.sh.old       2002-04-27 00:01:23.000000000 -0400
+++ ltmain.sh   2002-04-27 00:01:45.000000000 -0400
@@ -2894,7 +2894,18 @@
        if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
          eval cmds=\"$archive_expsym_cmds\"
        else
+         save_deplibs="$deplibs"
+         for conv in $convenience; do
+       tmp_deplibs=
+       for test_deplib in $deplibs; do
+         if test "$test_deplib" != "$conv"; then
+           tmp_deplibs="$tmp_deplibs $test_deplib"
+         fi
+       done
+       deplibs="$tmp_deplibs"
+         done
          eval cmds=\"$archive_cmds\"
+         deplibs="$save_deplibs"
        fi
        save_ifs="$IFS"; IFS='~'
        for cmd in $cmds; do

The DESTDIR bug: Certain packages which set DESTDIR and use libtool 1.4.2 have problems with relinking. The problems are discussed in these email messages:
http://mail.gnu.org/archive/html/libtool/2002-04/msg00019.html

http://mail.gnu.org/archive/html/libtool/2002-04/msg00021.html

http://mail.gnu.org/archive/html/libtool/2002-04/msg00025.html,

and a patch for the problem is discussed in:

http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html.

3.4 Further Notes

For more information on libtool itself and what it does, see the libtool homepage.

Side note: Apple's Developer Tools contain a program also called libtool, which is used by the compiler driver to build shared libraries. However, this is completely unrelated with GNU libtool. The GNU libtool that Apple ships is installed as glibtool instead. This can be achieved by configuring GNU libtool with --program-transform-name=s/libtool/glibtool/.

Next: 4. Preparing for 10.2