lua-users home
lua-l archive

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

Can someone explain this lua-as-dll-works-fine magic?

It is the (made in hell) linkage model.

1. Lua uses the RTL (runtime library)
2. when you use the RTL in VC, you have the choice of statically
linking everything, which is fine, except that it is not suitable for
dynamically loading DLLs that use the RTL.
If, for example, you were to try to have a luasocket.dll(statically linked)
loaded by a statically linked lua,exe, then you have a copy of the RTL
functions in the exe and a copy of the RTL functions in the DLL, whats
more you have copies Lua APIs in both modules.
The problem here is that the RTL requires some static initialization
that allocates memory, Question: which copy of the RTL code will
free it?
Next problem is that when you allocate memory in your application is
which malloc() will you use (you now have two mallocs).
This problem occurs because when you LINK the dll all the entry
points must be resolved at linkage time.

3. When you create a lua51.dll, this dll represents a library of functions
that can be shared by many callers (at runtime), hence lua.exe uses the
same physical code as luasocket.dll. Both lua.exe and lua51.dll use the
RTL so (thanks to /MD) they both use a DLL that contains the RTL
functions (one of MSVCRT.DLL, MSVCR71.DLL MSVCR71D.DLL etc etc
depending on your version of the compiler and whether your are debugging).
The trap here is that if you compile lua.exe with say /MDd and lua51.dll
with /MD, you also get two different runtime libraries in your application,
which means you get the same problem as in 2)

With a windows system and using RTL functions the rules are :
1) all components are compiled with the same /M(X) options
2) Make sure that only one copy of a each function exists in you EXE


If you which means that if you dynamically load lua