[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Adding module+DLL to Lua for Windows (LfW)
- From: Joshua Jensen <jjensen@...>
- Date: Thu, 10 Dec 2009 10:36:50 -0700
----- Original Message -----
From: Richter, Jörg
Date: 12/10/2009 9:53 AM
Sure, but that's an unnecessary pain in the neck. I also remember
reading somewhere once that the length of the new install name path
can't exceed the length of the old.
You can use install_name_tool to change this paths, like so:
install_name_tool -change<absolute-path> @executable_path/liblua.so
Unfortunately I found no easy way to do the equivalent (changing RPATH/RUNPATH) on Linux.
The build tool I maintain can use Lua (actually LuaPlus) as part of its
build. It does so in a directory structure similar to this:
-> jam executable
The executable dynamically loads the luaplus_1100.so, as it is
optional. When a Lua script is run that loads mymodule.so, it can't
open it. The install name path is @executable_path/modules/mymodule.dylib.
In order to just drop in a LuaPlus build, I have to start the Jam
executable, set the DYLD_FALLBACK_LIBRARY_PATH to
jamplus/bin/macosxx64/lua/, and then execute the Jam executable again in
order to have Mac OS X process the DYLD_FALLBACK_LIBRARY_PATH change.
On Windows, I am able to call LoadLibrary on lua/luaplus_1100.dll, and
when LoadLibrary is called on mymodule.dylib, it is able to find
luaplus_1100.dll already loaded in process memory.