Re: shared module chain under linux

[Jay Carlson <nop@...>]

On Fri, Feb 24, 2012 at 4:45 PM, Michal Kottman <k0mpjut0r@gmail.com> wrote:
> On 24 February 2012 15:15, Jay Carlson <nop@nop.com> wrote:
>> The reason the Lua distribution keeps on getting stuck
>> finding/explaining all these weirdo dynamic linker/loader options is
>> that under this rule, lxp.so should also link with -llua5.1. But
>> /usr/bin/lua is instead serving as an anonymous shared library--one
>> which cannot be called for by name. If targeting larger apps embedding
>> lua dynamically, plugins are stuck--should they declare their
>> dependency on -llua5.1?
>
> When I do this, I can no longer use the same module with LuaJIT,
> because the module loads the standard Lua VM and those two cause
> conflicts. Or at least that is my theory of why the modules I tested
> were causing obscure errors like segmentation faults and started
> working when I removed "-llua5.1" dependency. I may be wrong...

Yeah, I can believe that. I'm not sure what is to be done now. In some
sense luajit should claim the soname of liblua5.1 since it's
implementing the same interface, but dynamic resolution of symbols in
the presence of dlopen is one of those things where I know my
intuition is wrong and therefore when I think I've got it figured out
I later remember I didn't...even if I did.

If you talk to the Linux ld.so/binutils folks, they all say to avoid
unresolved symbols in dynamically loaded objects for new designs. They
also say "compile your damn DSOs with -fpic" too...

(If you are compiling with -fPIC instead of -fpic, please please
change it until you get a bug report from a SPARC user saying
something about the GOT overflowing. On some architectures, -fPIC
produces much less efficient code, and is only useful if the total
number of global symbols in your DSO gets over 8k or so.)

Jay