MacPorts on Lion (common issues, fixes, and workarounds)

Jeremy Huddleston jeremyhu at
Wed Jul 20 09:26:46 PDT 2011

MacPorts on Lion works fairly well out of the box with a few exceptions.  I've fixed a number of build issues already, so I'd like to share the common cases for other developers to benefit from:

1) Reinventing functionality added to Libc
Lion's Libc pulled in some new functionality from POSIX 2008 (although it does not implement everything).  In some cases, code may provide implementations of functions previously unavailable, and this can cause a conflict.  The most common offender of this is getline(3).

2) Hardening
Lion is a bit more hardened than Snow Leopard.  If your code is SIGBUSing, and you do funny things with memory (creating your own segments, setting -pagezero_size 0, executing code in heap, etc), you may need to link with -Wl,-no_pie and/or -Wl,-allow_heap_execute as appropriate.  Check ld(1) for more details.

3) llvm-gcc-4.2 doesn't build your port.
This is not unique to Lion, but its worth mentioning since MacPorts-2.0.0 is the first release that enables llvm-gcc-4.2 as a default compiler (on XCode 4.0 and later).  If llvm-gcc-4.2 doesn't build your port, try clang.  If clang works, great.  Just switch to clang instead (eg: look at firefox-x11):

if {${configure.compiler} == "llvm-gcc-4.2"} {
    configure.compiler clang

If both clang and llvm-gcc-4.2 fail to build, you can try falling back on gcc-4.2.  If gcc-4.2 works, you can fall back on it, but we recommend you try to fix the problem.  A common reason for both llvm-gcc and clang failing where gcc-4.2 works is buggy inline asm.  If you are unfamiliar with x86 asm, please file a bug with upstream developers and put a reference to it in the Portfile.

if {${configure.compiler} == "clang" ||
    ${configure.compiler} == "llvm-gcc-4.2"} {
    configure.compiler gcc-4.2
    if {![file executable ${}]} {
        depends_build-append port:apple-gcc42
        configure.compiler apple-gcc-4.2

wine and libsdl are the only two ports that I've run into that need to fall back on gcc-4.2

4) compiler codegen issues

As discussed on this list over the past month or so, we've run into some codegen issues when using llvm-gcc-4.2.  This will appear as a segfault, timeout, bad visual artifacts, or just plain weird behavior.  If something new like this coprs up, try rebuilding the relevant ports with a different compiler (preferably gcc-4.2 since that was what created the "known good" version).  If you find that works, bisect the relevant ports to find which port was built wrong.  Once you know the actual port that has codegen issues, try using clang instead of llvm-gcc-4.2.  If that doesn't work, please file a bug with Apple and llvm (and reference the bug number in the Portfile), then fall back on gcc-4.2 until it is addressed.

5) Building with a compiler that doesn't support newer __builtins

If your port uses MacPorts compilers rather than the default compiler, you may run into trouble with string functions.  You'll see errors at link time about undefined __builtin_* functions.  If this happens, you may want to compile with -D_FORTIFY_SOURCE=0 to tell the headers to use unfortified versions which do not use compiler builtins.

6) libnotify

The libnotify port is disabled on Lion.  This blocks gnome, firefox-x11, and other ports.  There is a hacky workaround discussed in the Portfile, but it is recommended for *experts only* ... I really can't stress that enough.  You should be comfortable booting from a recovery disk, using target disk mode, or otherwise gaining access to your FS to fix your system should something go wrong after following (or not quite following) my advise.  If any part of the workaround confuses you, DON'T DO IT!

I hope this helps,

More information about the macports-dev mailing list