lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Jul 7, 2014 at 1:16 PM, Coda Highland <> wrote:
On Mon, Jul 7, 2014 at 11:13 AM, Daurnimator <> wrote:
> On 7 July 2014 13:57, Enrico Tassi <> wrote:
>> Shared objects are names and, but
>> this is not enough.  You can have a library that is developed
>> by John and that links the former, and another library,,
>> developed by Jack that links the latter.  Now, if I want to use both
>> libfoo and libbar the loader has to load one fist, say foo, and in turn
>> this loads liblua5.1 with all its symbols.  When it is the turn of bar,
>> even if liblua5.2 is loaded, some symbols, say lua_pushinteger, are
>> already there and take precedence.  So you end up having bar using some
>> lua5.1 symbols expecting them to be lua5.2 symbols...
>> very nasty.
>> --
>> Enrico Tassi
> (Pardon my ignorance):
> Why is this an issue?
> Surely libfoo should be effectively calling:
>     h=dlopen("", RTLD_LOCAL)
>     f=dlsym(h, "lua_pushinteger")
> and then using `f`?

It's more like

if lua_pushinteger does not exist {
    open with RTLD_GLOBAL
use lua_pushinteger

So you can see the problem.

/s/ Adam

I'm still ignorant, but I'm getting closer.

Is it the case that two unrelated libraries cannot have a name clash?

My understanding is that: Lua 5.1 and Lua 5.2 are not to be considered "stand-ins" for each other.

I believe that You are saying that if a project uses both Lua 5.1 and Lua 5.2 (two dependent libraries, perhaps) and they dynamically link, then it all blows up. If the libraries link  statically with Lua this is not a problem. 

However, if all applications are each using a single version of Lua, then naming the 'so' file with the version would help, but not for all cases. To solve for all cases, you're back to the OP's proposal. Correct?

Thank you for your patience. 


Do I have this correct?