On 2010年4月30日 10:50:19 -0500 Rob Hoelz <rob@hoelzro.net> wrote: > On 2010年4月29日 21:50:55 -0700 > Brian Maher <brian@brimworks.com> wrote: > > > On Thu, Apr 29, 2010 at 9:02 AM, Rob Hoelz <rob@hoelzro.net> wrote: > > > lua: fail.lua:2: Can't load > > > '/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/auto/B/B.so' > > > for module > > > B: /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/auto/B/B.so: > > > undefined symbol: PL_opargs > > > at /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/XSLoader.pm > > > line 64. at /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/B.pm > > > line 316 > > > > The PL_opargs symbol should be coming from libperl. If you are > > statically linking in libperl into your lua implementation of > > perl.so, there is a good possibility that the linker is optimizing > > out PL_opargs. You could either build your perl with a libperl.so > > and link your perl.so as loaded by lua so it dynamically links > > against libperl.so, or you could tell your linker to link in the > > "whole archive" (-Wl,--whole-archive if you are using gcc frontend > > to ld). > > > > All of this is just my guess though ;-). > > > > Your project sounds really interesting to me. > > The only library I have for Perl is libperl.so, and I link against > that with the following options (generated by perl -MExtUtils::Embed > -e ldopts): > > -Wl,-E > -Wl,-rpath,/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE > -L/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE -lperl > -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc > > Running ldd on my perl.so Lua module results in this output: > > $ ldd perl.so > linux-vdso.so.1 => (0x00007fffe49ff000) > liblua-5.1.so => /usr/lib64/liblua-5.1.so (0x00007f6ababef000) > libm.so.6 => /lib64/libm.so.6 (0x00007f6aba96a000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f6aba766000) > libperl.so > => /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so > (0x00007f6aba3c1000) libresolv.so.2 => /lib64/libresolv.so.2 > (0x00007f6aba1a7000) libnsl.so.1 => /lib64/libnsl.so.1 > (0x00007f6ab9f8e000) libcrypt.so.1 => /lib64/libcrypt.so.1 > (0x00007f6ab9d57000) libutil.so.1 => /lib64/libutil.so.1 > (0x00007f6ab9b53000) libpthread.so.0 => /lib64/libpthread.so.0 > (0x00007f6ab9937000) libc.so.6 => /lib64/libc.so.6 > (0x00007f6ab95be000) /lib64/ld-linux-x86-64.so.2 (0x00000038c7400000) > libfreebl3.so => /lib64/libfreebl3.so (0x00007f6ab935e000) > > > > > > Compilation failed in require > > > at /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/Scalar/Util/PP.pm > > > line 15. BEGIN failed--compilation aborted > > > at /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/Scalar/Util/PP.pm > > > line 15. Compilation failed in require > > > at /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/Scalar/Util.pm > > > line 21. Compilation failed in require at (eval 1) line 1. > > > > > > stack traceback: > > > [C]: in function 'assert' > > > fail.lua:2: in main chunk > > > [C]: ? > > > > > > On 2010年4月28日 16:08:42 -0500 > > > Rob Hoelz <rob@hoelzro.net> wrote: > > > > > >> Hello lua-l, > > >> > > >> As indicated by my e-mail this morning, I'm writing a Lua-Perl > > >> bridge. I've run into a bit of a snag. > > >> > > >> I've written perl.c, which currently just allows you to evaluate > > >> strings of Perl code from Lua. However, when I load a dynamic > > >> module from Perl (ex. Scalar::Util), I get errors relating to > > >> undefined symbols. This probably stems from the fact that I have > > >> a standalone Lua interpreter loading a shared object (perl.so) > > >> that loads another shared object (libperl.so) that uses a dynamic > > >> loader (Perl's DynaLoader) to load another shared object (in the > > >> case of Scalar::Util, List/Util/Util.so). I understand the > > >> basics of linking, but this is beyond my current knowledge. > > >> > > >> Attached are three files: > > >> > > >> - perl.c, which defines the Lua bindings to my Perl bridge. > > >> - Makefile - self explanatory > > >> - fail.lua - After running make, run 'lua fail.lua' and you'll > > >> see the errors. > > >> > > >> Note: If I compile my perl.c into standalone Lua, fail.lua passes > > >> fine. > > >> > > >> I should specify that I'm on 64-bit Fedora 12. > > >> > > >> If anyone with a greater knowledge of linking could take a look > > >> at this and give me any insight, I'd be very grateful. > > >> > > >> Thanks, > > >> Rob Hoelz > > > > > > > > > > > > > Alright, I believe I've solved the problem (kind of). I wrote a test program that simulates the above situation, only sans Perl and sans Lua. I reproduced that same linker issue, and then I experimented from there to see what I could do to resolve it. It turns out if I load perl.so (the equivalent of my Lua module) using the dlopen flag RTLD_GLOBAL, that solves the problem! Now it's a matter of telling Lua to do that...=/ Just thought I'd give everyone a progress report! -Rob
Attachment:
signature.asc
Description: PGP signature