Dmacks: /* Common Libtool Linking Problems */

2007-01-26T23:18:28Z

Common Libtool Linking Problems

New page

{{Fink_Header}}

This page explains some of the common 'gotchas' encountered when porting packages to OS X. It is not inclusive, and is only meant to be a list of the more commonly encountered changes that need to be done to packages.

===Compiler Flags===

The following flags are not valid on Darwin:

* '-undefined suppress'

===Nested Functions in GCC 4.0.1 (XCode 2.2)===

See [[Fink:Package_issues#Nested_functions_issue_from_XCode_2.2_.28gcc-4.0.1.29]]
and also [http://developer.apple.com/technotes/tn2006/tn2161.html Apple's Technical Note on Nested Functions].

===The "head" command===

The program "<code>head</code>" from [http://pdb.finkproject.org/pdb/package.php/textutils <code>Textutils</code>] builds differently in 10.3 and 10.4, even though they are the same upstream version. The 10.4 build seems to be stricter in failing with the format "<code>head -1</code>". If your code uses head, make sure you use the "<code>head -n 1</code>" format, which is more explicit.

===The _environ symbol===

The missing <code>_environ</code> symbol is a common problem when porting to OS
X. Here's the standard patch used in several fink packages:

<pre>+#ifdef __APPLE__
+#include <crt_externs.h>
+#define environ (*_NSGetEnviron())
+#else
extern char **environ;
+#endif</pre>

A more portable solution is to have <code>configure</code> check for the presence of that header and symbol directly--"test for the actual feature instead of attempting to divine the features from the platform". Add

<pre>AC_CHECK_HEADERS(crt_externs.h)
AC_CHECK_FUNCS(_NSGetEnviron)</pre>

to <code>configure.ac</code> or <code>configure.in</code> and use this patch for the source file:

<pre>+#ifdef HAVE_CRT_EXTERNS_H
+#include <crt_externs.h>
+#endif
+#ifdef HAVE__NSGETENVIRON
+#define environ (*_NSGetEnviron())
+#else
extern char **environ;
+#endif</pre>

to implement the results of the AC_CHECK_* tests.

An alternative portable solution is to [http://bugzilla.gnome.org/show_bug.cgi?id=124277 rewrite the code] to use <code>g_listenv()</code> (requires glib >= 2.8.0).

===Common Libtool Linking Problems===

There are several commonly-encountered library linking problems that have relatively simple solutions.

# On older libtool, relinking fails. This patch solves it:<pre>perl -pi -e 's/need_relink=yes/need_relink=no/g' ltmain.sh</pre>
# An installed copy of the library is passed to the linker instead of the one being (re)built. That is, even if libfoo, which supplies /sw/lib/libfoo.dylib, is installed, building the libfoo package again should link other files against the libfoo shared library in the local build directory. A command like <code>gcc -o libfoo-demo -L/sw/lib -L. -lfoo</code> is wrong, and should instead be <code>gcc -o libfoo-demo -L/sw/lib ./libfoo.dylib</code> (i.e., explicit filename instead of gcc search paths). There are several possible causes:
## A bug in older libtool. This patch solves it:<pre>perl -pi -e 's/hardcode_direct=yes/hardcode_direct=no/g' configure</pre>
## Bugs in packages' makefiles. They pass <code>LDFLAGS=-L$(build_dir) -lfoo</code> instead of <code>LDFLAGS=$(build_dir)/libfoo.dylib</code> (or <code>LIBADD=$(build_dir)/libfoo.la</code>)
## Package maintainers' using some variant of the broken LDFLAGS syntax to fix some other problem.

[[Category: Fink|Porting Notes]]
[[Category: Fink_Documentation|Porting Notes]]

{{Fink_Header}}

Fink:Porting Notes - Revision history

Dmacks: /* Common Libtool Linking Problems */