lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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'.