Re: Using Lua in dynamic modules with static linking

[Chris Smith <space.dandy@...>]

> On 27 Feb 2019, at 01:05, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
> 
>>>>>> "Chris" == Chris Smith <space.dandy@icloud.com> writes:
> 
> Chris> If I understand correctly, the two caveats you detail only apply
> Chris> because the main application is dynamically linked to the Lua
> Chris> library? If I statically linked both application and module to
> Chris> their respective Lua libraries then I wouldn’t expect any
> Chris> issues, correct?
> 
> Incorrect at least on ELF platforms (I don't know about MacOS), and this
> is exactly the problem that bit us in PostgreSQL.
> 
> Our scenario went like this: libpgcommon.a (a static library) comes in
> multiple versions: libpgcommon.a is for the frontend, libpgcommon_srv.a
> is for the backend. They define the same functions but with different
> implementations.
> 
> The main application, "postgres", is linked statically to
> libpgcommon_srv.a. "postgres" can (on request) dynamically load the
> module "postgres_fdw.so" with dlopen; postgres_fdw.so is dynamically
> linked against libpq.so, which is statically linked against
> libpgcommon.a.
> 
> What we found is that on platforms where we weren't using a version
> script to hide symbols, libpq.so's calls to functions in libpgcommon
> were actually being resolved not to the ones statically linked into
> libpq.so, but to the copies from the "postgres" binary which of course
> came from libpgcommon_srv.a; we had crashes as a result. See e.g.
> https://www.postgresql.org/message-id/flat/153626613985.23143.4743626885618266803%40wrigleys.postgresql.org


I admit I didn’t fully believe this, but I wrote a small test and mostly confirmed that you are right.  As I write this I realise that I didn’t recreate your situation exactly in my test and missed one level of indirection; my test is effectively this:

  (app —static—> lib_a) —dlopen—> (module —static—> lib_b)

Where lib_a and lib_b have identical function interfaces.  In this situation, for me, it works perfectly: lib_a provides the functions for app and lib_b provides the functions for module.  However, if I replace ‘dlopen’ with ’shared’, then lib_a provides everything.  (On OS X, shared also works perfectly.). Fortunately, the working dlopen scenario is what I need, so this may work for me (if my test isn’t just a fluke).

I feel like I’m missing something though, because this should mean that shared libraries are almost unusable.  Apps should be going haywire all over the place due to clashing function names.

Regards,
Chris
—
Chris Smith <space.dandy@icloud.com>