[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Tidying up search path for C modules.
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Sat, 27 Aug 2011 17:23:24 +0200
On 27/08/2011 16.58, Should Pain wrote:
于 2011-8-26 21:44, Lorenzo Donati 写道:
Some time ago I wanted to clean up my C search path, which began
looking as a trash bin full of unrelated DLLs side by side to lua.exe.
I tried to put different libraries in different subdirs, but then for
example this idiom didn't work any longer:
local lfs = require 'lfs'
if I did not mis-understood you, maybe what you could try is like this
(see the document for `package.cpath'):
> -- suppose you have already set the variable `root'
> -- ROOT = "/"
> package.cpath = ROOT .. "/?/?.dll" .. package.cpath
> -- or for windows, maybe use this form
> package.cpath = ROOT .. "\\?\\?.dll" .. package.cpath
then, this statement
> require "lpeg"
would just load "ROOT/lpeg/lpeg.so" or "ROOT\lpeg\lpeg.dll"
Thank you for the feedback.
Yes I know that, but this works just because lpeg has only one DLL which
depends only on known system DLLs. It won't work with other libraries
consisting of more than one DLLs that link to each other.
This is definitely a Windows issue - by default the Windows dynamic
linker resolves the links starting from the directory where the
executable is placed - in this case lua.exe. But if in a Lua script I have:
and the library 'foo' is implemented as foo.dll, and this in turn is
linked against bar.dll, then when loading foo.dll, the dynamic linker
will look for bar.dll in the directory of lua.exe, not in the directory
of foo.dll. So the "dirty" solution is to place every dll side by side
to lua.exe, which is a mess (the term "DLL hell" was coined to describe
One could use the Windows API function LoadLibraryEx with a special
flag: LOAD_WITH_ALTERED_SEARCH_PATH, which changes the default behaviour
of the dynamic linker, but this requires changing Lua sources (I did
that already and it goes ok). The problem is that I use several
different Lua versions (5.1.4, customized 5.1.4, 5.2) and I want to keep
my library in one place without duplicating them. So my complicated
solution was an attempt to keep all my "interpreters" happy.
The big IF is that I don't know if what I did is ok, within the limits
of the approach, or if it is a time bomb waiting to explode in my face :-)