Re: A weird bug with luaL_Reg array

[tehtmi <tehtmi@...>]

Not an expert on dynamic linking (or Window/Linux APIs), but it seems 
there is a difference in the way Windows (LoadLibrary) vs Linux (dlopen) 
treat global variables in dynamic linked libraries. By default, Windows 
will not export/share global variables between modules, but Linux will. 
Windows has separate notions for symbols that are shared between modules 
(ie dllimport/dllexport) versus variables that are just global (external 
linkage) within a module; but I guess Linux doesn't distinguish these, 
so everything with external linkage is subject to dynamic linking.

I'm assuming this is the problem.

On 2022-07-01 12:39 AM, Shmuel Zeigerman wrote:
> 1. Whether the lack of the word 'static' is a bug here?

On Linux, probably yes. The 'methods' array definition should not be 
shared with other modules, so you should give it internal linkage via 
'static'. (Aside: in C++, const declarations get internal linkage by 
default, but this is not true in C.) On Windows, probably this is not a 
bug. (But, probably it is a good practice to use internal linkage in 
this kind of situation regardless of this specific problem.)

> ['methods'] should have been resolved at compile time because the 
> compiler sees its definition above.
I think even without dynamic linking, symbols with external linkage 
cannot be resolved at compile time. They have to be resolved at link 
time in case they are used in multiple translation units that would have 
to share the symbol. If the dynamic linking implementation wants to 
share a symbol between modules, then its resolution would have to be 
further delayed until the module is actually loaded.

> 2. Does some GCC switch exist to prevent such behavior?
Not that I know of. Possibly (if you are supplying Lua), using 'dlopen' 
with RTLD_DEEPBIND might avoid this kind of problem, but I'm not really 
sure; Lua calls 'dlopen' in 'loadlib.c'.