On Sep 22, 2004, at 5:30 PM, Will Coleda (via RT) wrote:
...# New Ticket Created by Will Coleda # Please include the string: [perl #31682] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31682 >
...$ make realclean $ export LD_LIBRARY_PATH=.:blib/lib $ perl Configure.pl $ make $ make shared $ cd dynclasses; make
On OSX 10.3.5, I end up with:
ld: /Users/coke/research/parrot/blib/lib/libparrot.dylib is input for the dynamic link editor, is not relocatable by the static link editor again
As for the next error... huh?
Yeah, this is going to be a fun config dance. On Mac OS X, there are two distinct types of dynamic libraries--those which are meant to be linked against and automatically loaded at runtime (dylibs), and those which are meant to be "manually" loaded (bundles).
libparrot needs to be built as a dylib
things in dynclasses (or other "plug-in"-like stuff) need to be built as bundles
The Makefiles don't have this conceptual split currently, and so things (including libparrot) are being built as bundles, but getting the dylib extension (running the 'file' command on the library reveals the truth). A bit Frankenstein.
I worked out in the past the right configs to build parrot shared on Mac OS X, but I don't think I'd yet wired the Makefiles (and config process) to do that, and still have the "other stuff" build as bundles. I'll dig this up and see what I did.
JEff
