Re: shared library, symbols names and Linux distributions

[Andrew Starks <andrew.starks@...>]

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

On Mon, Jul 7, 2014 at 12:47 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> 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.

You are correct. If the libraries link statically with Lua then they
won't be touching the dynamic loader. They'll have their symbols
resolve at build-time, and ideally they'll be built so that they don't
themselves export the Lua symbols. (This means those libraries can't
dynamically load other Lua libraries, though!)

> 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?

Yup. You've got it.

Qt (a large C++ library) offers a configure option to encapsulate the
entire library in a namespace, which disambiguates the symbols, as
well as an option to modify the naming pattern of the .so files,
allowing the libraries to be distinguished at load time. This is, in
essence, equivalent to the OP's proposal, with less macro magic
because C++.

/s/ Adam

Unless you're wrong, I'm now smarter, and so thank you! :)

-Andrew