|
----- 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:
-> jamplus/bin/macosxx64/ -> jam executable -> lua/ -> luaplus_1100.so -> modules/ -> mymodule.dylibThe 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.
Josh