I assume you're referring to the problem of multiple libjpegs being used and not problems with gmp/nettle compilation...
It's been a while since I did that; I recall that multi-level namespaces were added somewhere after 10.1 and that a lot of things were broken by it (not just pike, but libraries as well). It's possible that it's not required any more, however I can't say for sure. I think that one of the problems is that if you don't use flat_namespace, you have to have anything that links to it be available for the linker to scan. Versions since 10.3 have complicated matters more, by adding/changing behavior. Since pike modules tend to be built before pike, this was the source of multiple problems. It's worth noting that adding the MACOSX_DEPLOYMENT_TARGET effectively specifies the earliest version of OSX that can be used.
The OSX linker is a much different beast than those on other *nix platforms... the ld man page has lots of interesting and frustrating information about the divergent path apple/next took. I think 10.5 changes things yet again. Makes me really appreciate the relative stability of solaris over the years.
Bill
On Aug 14, 2008, at 12:20 PM, Jonas Walldén @ Pike developers forum wrote:
More testing shows that if I restore two-level namespace linking for OS X the resulting Pike works fine again. This means switching from
LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -flat_namespace - undefined suppress"
to
LDSHARED="$REALCC $CFLAGS -bundle -bind_at_load -undefined dynamic_lookup"
combined with "export MACOSX_DEPLOYMENT_TARGET=10.4".
In src/configure.in r1.568 Grubba added Bill's patch for bug #2820 which forced flat namespace (i.e. the OS X 10.0 default link mode). This bug ticket says:
After considerable fiddling, it appears that it will be necessary to use the flat namespace when compiling for Darwin (ask me offline if you need specific examples and reasons).