lua-users home
lua-l archive

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

于 2011-8-27 23:23, Lorenzo Donati 写道:
On 27/08/2011 16.58, Should Pain wrote:
于 2011-8-26 21:44, Lorenzo Donati 写道:
Hi All!

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/" 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:

require 'foo'

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 this).

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 :-)

-- Lorenzo

well, in fact the search path when Windows loads a dll is as following (in order)(see MSDN):

  1. The directory where the executable module for the current process is located.

  2. The current directory.

  3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.

  4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.

  5. The directories listed in the PATH environment variable.

when the dependenies are not so many, I would prefer to put them into one single directory, and add this directory to the PATH envirenment variable(on Linux, the LD_LIBRARY_PATH variable)

I can set the env in user login/startup script, or in lua script.

I don't like to scatter dlls in many directories. at all, they are SHARED libraries, and there should not be so many of them.

But I suppose this is more about personal taste.

since you would only run it on Windows, you could just do it in platform (Windows) specific way as package.loadlib or so.

as long as you don't move to different platform, the package.loadlib works just fine. nothing to worry.

My opinion. Hopefully useful.