Andy Dougherty via RT wrote:
+
+ unless osname == 'darwin' goto not_darwin
+ link .= '-undefined dynamic_lookup '
+ not_darwin:
+
I understand and sympathize with wanting to just get past this problem,
but this looks to me like layering more magic to undo the bad magic
applied earlier. It doesn't look sustainable, maintainable, or even
likely to be right in the long run. I can't test any of this myself,
and it may be that gcc/ld isn't quite getting the symbol hiding stuff
right anyway.
I admit I'm eager to be able compile Parrot (I can't really work on any
other part of Parrot until I can compile it), but adding '-undefined
dynamic_lookup' isn't a naive hack just to get it to compile. (Adding
'-undefined suppress' would be.)
From 'man ld':
"-undefined dynamic_lookup can also be used to allow any undefined
symbols to be looked up dynamically at runtime."
"...at execution time the dynamic linker will search that umbrella
framework's sub-frameworks, sub-umbrellas and sub-libraries for those
references."
Some documentation on symbols in OS X:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/executing_files.html
What I'd be tempted to do is rip all the hiding stuff and the 'undefined
suppress' out of the darwin hints and go back to the static build.
Using '-undefined suppress' (or '-undefined dynamic_lookup') when
linking libparrot.dylib is necessary for libraries that Parrot uses, not
just for Parrot internals.
See <http://mail-index4.netbsd.org/pkgsrc-bugs/2006/02/05/0039.html>,
which was also an "Undefined symbol: _environ" error, the same as Parrot
gets if you leave '-undefined' set to the default '-undefined error'.
Actually, in most places I read, it's recommended to use '-undefined
dynamic_lookup' without '-flat_namespace'. It doesn't work before 10.3,
but that seems like an acceptable loss.
The dynamic build doesn't buy you anything anyway. You can't install
it, it doesn't make parrot run any faster, and it doesn't save you
significantly on disk space since there aren't lots of executables
embedding the parrot interpreter. It's just wasting your time.
I'd say rip it out and let someone who understands all the darwin-specific
behavior well worry about putting it in, *commenting it in the hints
file*, and maintaining it.
Going back to a static build was the first thing I tried. Unsuccessful.
If we have to mess around with linking issues anyway, we might as well
spend the effort on the dynamic library and get it right the first time.
(There is an advantage to not requiring everyone who embeds Parrot to
statically compile it into their program. See
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/OverviewOfDynamicLibraries.html.)
Allison
