On Mon, 4 Jun 2007, Mark Glines wrote: > On Mon, 4 Jun 2007 13:07:18 -0700 > chromatic <[EMAIL PROTECTED]> wrote: > > > On Monday 04 June 2007 12:49:45 Mark Glines wrote: > > > > > (the LD_LIBRARY_PATH bit is required on freebsd so parrot can find > > > libparrot.so.) > > > > The GNU linker supports a flag to mark a relocatable shared library. > > From my Makefile: > > > > -Wl,-rpath=/home/chromatic/dev/parrot/blib/lib > > > > I don't know which linker you use on FreeBSD, but is there a similar > > flag? If so, using it could clear up some of the dynamic loading > > problems (especially for dynops and dynpmcs). > > $ ld --version > GNU ld version 2.15 [FreeBSD] 2004-05-23 > > So it probably supports that flag. I know next to nothing about > FreeBSD, but here's how libparrot.so.* is currently linked: > > cc -shared -L/usr/local/lib -Wl,-E -L/usr/local/lib -o > blib/lib/libparrot.so.0.4.12 -Wl,-soname=libparrot.so.0.4.12 [list of > objects] -lm -lcrypt -lutil -pthread -lreadline > > Soo... is that just something missing from the freebsd hints file, > then?
In my opinion, you shouldn't bother with the shared libparrot at the moment anyway, and should just delete the parrot_is_shared setting from the freebsd hints file. The -rpath stuff is a temporary hack anyway. When parrot is finally installed, you don't want the installed parrot looking in your build directory. This is a problem that must be addressed eventually, of course, but there are more pressing issues to worry about now (such as the GC bug at the beginning of this thread). -- Andy Dougherty [EMAIL PROTECTED]