Re: Using Lua in dynamic modules with static linking

[Andrew Gierth <andrew@...>]

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

-- 
Andrew.