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).
