Re: Lua Perl Bridge

[Rob Hoelz <rob@...>]

On Fri, 30 Apr 2010 10:50:19 -0500
Rob Hoelz <rob@hoelzro.net> wrote:

> On Thu, 29 Apr 2010 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 Wed, 28 Apr 2010 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!  So I have my Makefile build a
dummy .so that requires libperl.so and load that in luaopen_perl.

Just thought I'd let everyone know I solved the issue.

-Rob

Attachment: signature.asc
Description: PGP signature