[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: static linked lua with loaded modules
- From: Stefan Sandberg <keffo.sandberg@...>
- Date: Wed, 05 Dec 2007 20:38:09 +0100
Right, sometimes it works, sometimes it doesn't, but it -should- imo not
work, it's incorrect sortof..
Did you link stuff to symbols exported from your exe? A lot of people on
#lua have asked for that lately, so it would be cool for reference if
you could spit out how to do that.
Geoff Leyland wrote:
On 6/12/2007, at 7:30 AM, John Dunn wrote:
Is it possible to have my app statically link to lua but also allow for
DLL based packages to work correctly? I'd like to add support for
sockets in my library using the luasockets package. I've built the
sockets library so it links to a static version of the lua library and
it appears to work.I know that by having the app and package statically
link they each end up with their own copy of lua - Is this a really bad
I used to statically link Lua into one of my apps on windows. At
first I statically linked all the libraries (lfs, luazip) in too into
one executable. That worked pretty well, and there was only one file
Then I statically linked Lua, exported all the Lua symbols from the
app, and dynamically linked lfs and luazip to that. I used the
multi-threaded DLL run-time and that worked fine.
Now I do dynamically link Lua, and that works too.
I have seen luasockets crash a few times - could the multiple copies of
lualib cause this sort of thing? In general, is statically linking a bad
idea when using .dll based packages?
I accidentally used a luazip from a lua.dll, but the luazip was linked
to a lua5.1.dll - and it managed to find one of those on the path. It
actually worked, but I really don't think it's a good idea.
(especially when things mysteriously didn't work on machines where
luazip couldn't find a lua5.1.dll).