On Tue, 5 Jun 2007 01:13:36 -0500 Joshua Isom <[EMAIL PROTECTED]> wrote:
> After a little prodding around, I think the problem is that the > dynops aren't build with the rpath. I don't know how "proper" the > following patch is(i.e. linux doesn't seem to have a problem so > either this is right or the other way is right), but it does the > trick. > -our $LDFLAGS = [EMAIL PROTECTED]@ @[EMAIL PROTECTED]; > +our $LDFLAGS = [EMAIL PROTECTED]@ @ld_debug@ @[EMAIL PROTECTED]; Sorry, but this patch didn't change anything for me. The libparrot.so link line looks the same (maybe because its linking with cc, not ld), and I still need to specify an LD_LIBRARY_PATH when invoking parrot from a subdir, later on. Since it works on linux but not freebsd, and since freebsd seems to have the same tools available as linux, could it just be a difference in the hints files? [EMAIL PROTECTED] ~/parrot $ grep rpath config/init/hints/freebsd.pm config/init/hints/linux.pm config/init/hints/freebsd.pm: rpath => '-Wl,-R', config/init/hints/linux.pm: rpath => '-Wl,-rpath=', On the other hand, I don't see an actual "-Wl,-rpath=" clause on the linker line for a linux build, either. And the result works on linux without any LD_LIBRARY_PATH hints, but not on freebsd. Linker line under linux: i686-pc-linux-gnu-gcc -shared -L/usr/local/lib -fPIC -L/usr/local/lib -o blib/lib/libparrot.so.0.4.12 -Wl,-soname=libparrot.so.0.4.12 [long list of objects] -lpthread -lnsl -ldl -lm -lcrypt -lutil -lrt -lgmp -lreadline -lncurses -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm Linker line under freebsd: 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 [long list of objects] -lm -lcrypt -lutil -pthread -lreadline Mark
