[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: A weird bug with luaL_Reg array
- From: tehtmi <tehtmi@...>
- Date: Fri, 1 Jul 2022 05:42:37 -0700
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.
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'.
2. Does some GCC switch exist to prevent such behavior?