Re: Tidying up search path for C modules.

[Peng Zhicheng <pengzhicheng1986@...>]

于 2011-8-29 13:30, Lorenzo Donati 写道:
> On 27/08/2011 19.51, Dimiter "malkia" Stanev wrote:
> [...]
> > >
> How can you *set* an env var in Lua? You can only use os.getenv to retrieve their value. There is no os.setenv. Are you using a patched version or a C add-on to do it?

yes, I do use add-on to to it, although there is no ANSI way to set environment variable,
there is a putenv in <stdlib.h> most platforms.
and on POSIX platforms, we have setenv/unsetenv too, and there is a package for posix platforms.
  see luaposix at [http://luaforge.net/projects/luaposix/] or [http://git.alpinelinux.org/cgit/luaposix]

> > >
>
> The problem, at least on Windows, is versioning and naming conflicts. There is no way AFAIK to tell the dynamic linker you want to link against a specific version of a DLL. It only cares about its name. So usually versioning is done by putting numbers in the name itself. But this is usual practice only for major versions, if ever. I've run several times into equally named DLLs (bundled with different apps) but which have different minor version number. It is supposed that the DLL author *should* have preserved backward compatibility when fixing a bug, but you never know...

this is the really big problem of Windows, A.K.A. the "DLL Hell".
I don't know elegant way to solve this. if someone has good idea, don't hesitate to share it.

Although MS introduced the so called "side by side assembly" (WinSxS) trying to solve the problme, but I don't know much of it.
I found it actually more bad than good. someone even call it the "DLL Hell 2.0".
And as I have learned, it is limited to VC runtime library (did I lost something?).

I heard the VS Studio 2010 introduces new deploy model, but I have not see to it by now.

> > >
>
> Ah! Good point! I did not consider that my approach is platform specific. Not a problem for me now, but good to know. Thanks!
maybe I used not so accurate words here, but this should not confuse people I think. by `platform specific' I mean here the non-ANSI code which may use different implementation on different platform.

in Lua 5.1 Reference Manual, the package.loadlib is said this: "This function is not supported by ANSI C. As such, it is only available on some platforms ".
we can know from the source code (see lloadlib.c for details) that On Windows, it uses the Win32 API such as LoadLibraryA, GetProcAddress and so on; on some *nix platform, it uses libdl(#include <dlfcn.h>) when available.

besides, I name it 'platform specific' also because the filename of shared libraries may differ for different platforms.