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]
