Fink:Porting Notes

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 Apple's Technical Note on Nested Functions.

The "head" command

The program "head" from Textutils 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 "head -1". If your code uses head, make sure you use the "head -n 1" format, which is more explicit.

The _environ symbol

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

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

A more portable solution is to have configure 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

AC_CHECK_HEADERS(crt_externs.h)
AC_CHECK_FUNCS(_NSGetEnviron)

to configure.ac or configure.in and use this patch for the source file:

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

to implement the results of the AC_CHECK_* tests.

An alternative portable solution is to rewrite the code to use g_listenv() (requires glib >= 2.8.0).

Common Libtool Linking Problems

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

1. On older libtool, relinking fails. This patch solves it:

   perl -pi -e 's/need_relink=yes/need_relink=no/g' ltmain.sh

2. 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 gcc -o libfoo-demo -L/sw/lib -L. -lfoo is wrong, and should instead be gcc -o libfoo-demo -L/sw/lib ./libfoo.dylib (i.e., explicit filename instead of gcc search paths). There are several possible causes:
   1. A bug in older libtool. This patch solves it:

      perl -pi -e 's/hardcode_direct=yes/hardcode_direct=no/g' configure

   2. Bugs in packages' makefiles. They pass LDFLAGS=-L$(build_dir) -lfoo instead of LDFLAGS=$(build_dir)/libfoo.dylib (or LIBADD=$(build_dir)/libfoo.la)
   3. Package maintainers' using some variant of the broken LDFLAGS syntax to fix some other problem.