Re: shared library, symbols names and Linux distributions

On Mon, Jul 7, 2014 at 1:16 PM, Coda Highland <chighland@gmail.com> wrote:

On Mon, Jul 7, 2014 at 11:13 AM, Daurnimator <quae@daurnimator.com> wrote:
> On 7 July 2014 13:57, Enrico Tassi <gares@fettunta.org> wrote:
>>
>> Shared objects are names liblua5.1.so.0.0.0 and liblua5.2.so.0.0.0, but
>> this is not enough. You can have a library libfoo.so that is developed
>> by John and that links the former, and another library, libbar.so,
>> 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("liblua5.1.so.0.0.0", RTLD_LOCAL)
> f=dlsym(h, "lua_pushinteger")
> and then using `f`?

It's more like

if lua_pushinteger does not exist {
open liblua5.1.so.0.0.0 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.

-Andrew

Do I have this correct?