[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua Perl Bridge
- From: Rob Hoelz <rob@...>
- Date: Tue, 4 May 2010 09:26:58 -0500
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! 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