Re: [ANN] LuaBinaries 5.2 Released

[David Manura <dm.lua@...>]

On Wed, Dec 21, 2011 at 1:57 PM, Antonio Scuri <scuri@tecgraf.puc-rio.br> wrote:
>  The only change we do in the Lua source files is in the "luaconf.h" file
> at the LUA_CPATH_DEFAULT definition to add support for the "52" suffix in
> modules. Other files are only added to the standard distribution to compose
> the LuaBinaries packages.

There might be some concerns if a C module happened to have a 51 or 52
suffix in its module name (e.g. I had been thinking of a `_ENV =
require '_G51'` to load a 5.1 compatible environment into 5.2, and Lua
itself has its "bit32" module distinct from "bit").  It's good that
the 51/52 suffix is searched after the blank suffix in the C loader,
but the all-in-one loader is called after the C loader.  So, in the
case (however remote) you'd want require "foo52" to load from
foo52.dll and require "foo" to load from the all-in-one loader, that
won't work here *unless* you rename the foo52.dll to foo5252.dll
(ugly).  A suffix "-lua52" would not only be more clear (and avoid
ambiguities once Lua 25.2 comes around :)), and I don't think it would
interfere with Lua's "a.v1-b.c" style module naming feature, but it
also more directly addresses the system DLL naming conflict problem
discussed in [2].  loadall.dll/so may warrant a suffix as well.

The use of the "lib" prefix below seems odd to me since, as discussed
in [2], the "lib" is usually what distinguishes system libraries
(libtiff) from loadable modules (tiff), both of which would be
expected to be loaded into the same process.

  #define LUA_CPATH_DEFAULT \
  		LUA_CDIR"?.so;" LUA_CDIR"loadall.so;" "./?.so" \
      LUA_CDIR"lib?52.so;" "./lib?52.so"

One thing that probably should be mentioned in the specification [1]
is that lua5.1.def exports private functions (luaU_dump, luaM_toobig,
luaM_realloc_, luaS_newlstr, luaD_growstack, luaF_newproto), but
lua52.def does not.

[1] http://luabinaries.sourceforge.net/configuration.html
[2] http://lua-users.org/wiki/LoadLibrary

> "For Lua 5.2  We choose the MingW gcc 4 compiler to build the LuaBinaries executables.[...]
> The Visual C++ 8 MSVCR80.DLL was hard to be used because of two factors: its installation
> and the need of a manifest file to build the user modules."
> -- http://luabinaries.sourceforge.net/manual.html

That's a valid choice, but it's worth noting that the manifest thing
is backpedaled in MSVCR100.DLL [3,4].  Another factor to be weighed is
64-bit file I/O support (_fseeki64) [5].

[3] http://stackoverflow.com/questions/6623780/visual-c-2010-changes-to-msvc-runtime-deployment-no-more-sxs-with-manifest
[4] http://msdn.microsoft.com/en-us/library/dd293574.aspx
[5] http://lua-users.org/lists/lua-l/2011-11/msg00913.html