nvs/lua-stormlib

A Lua binding to StormLib

lua-stormlib's Issues

Issue building on Ubuntu

Having an issue building gem td on Ubuntu currently. Error is as so:

j@DESKTOP-D6S7COI:/mnt/c/Users/j/code/gem$ lua map/build etc/gem.lua
Building...
lua: error loading module 'stormlib' from file '/usr/local/lib/lua/5.3/stormlib.so':
        /usr/local/lib/lua/5.3/stormlib.so: undefined symbol: __gxx_personality_v0
stack traceback:
        [C]: in ?
        [C]: in function 'require'
        ./map/file/w3x.lua:7: in main chunk
        [C]: in function 'require'
        ./map/task/build/w3x/read.lua:4: in main chunk
        [C]: in function 'require'
        ./map/tasks.lua:73: in function 'map.tasks.run'
        (...tail calls...)
        [C]: in ?
        

For reference, here's the cmake command I'm using to build StormLib:
cmake -DCMAKE_CXX_FLAGS=-"fPIC -lstdc++" -DCMAKE_C_FLAGS="-fPIC -lstdc++" -DCMAKE_BUILD_TYPE=debug -DJSONCPP_LIB_BUILD_STATIC=ON -DJSONCPP_LIB_BUILD_SHARED=OFF -G "Unix Makefiles" CMakeLists.txt

Any idea what's going on here?

Create a MPQ archive

Stormlib has the functionality. However, lua-stormlib does not expose it. Probably best to allow that, then projects would have that option. This would basically be w mode on opening an MPQ.

Add a makefile

Rather than use the default (and effortless) Luarocks configuration, see about using a Makefile. This would simplify installation for people who do not wish to use Luarocks.

`file:read (number)` returns `number` instead of actual bytes in Lua 5.1/LuaJIT

For some reason, using file:read (number) does not return actual bytes read. Instead, it returns number. Lack of testing on anything but Lua 5.3 is the reason this bug has gone unnoticed for so long.

Name clash on Windows with DLL files

StormLib (defaults):

• Linux: libstorm.so
• Windows: stormlib.dll

lua-stormlib:

• Linux: stormlib.so
• Windows: stormlib.dll

This clash on Windows using MSVC runs into fatal error LNK1149. Linux presents no issue, even if trying to generate libstorm.so. Probably best to just have lua-stormlib build storm.so on Linux and storm.dll on Windows.

In another matter, this means lua-stormlib is looking for storm on Linux, but stormlib on Windows. I think LuaRocks allows some conditional stuff depending on platform. Would be best to target StormLib defaults.

Edit: This only happens when I don't clean after building, and thus there is a local stormlib.dll that gets picked up (and subsequently used). Given that I won't remember this fact later, probably best to set things up to avoid this name clash. Now, in the event that the PATH has some of the same elements as the LUA_CPATH, then there could be further issues. Overall, the best plan is to probably ensure the name used in the require is sufficiently different.

local storm = require ('storm')

This doesn't seem too bad. Except if someone has an original storm.dll around.

Error LuaRocks build Windows

I have this error :

SBaseFileTable.obj : error LNK2019: unresolved external symbol GetBits referenced in GetFileEntryExact function
  Advice on the symbols defined and likely to correspond :
    "public: void __cdecl TMPQBits::GetBits(unsigned int,unsigned int,void *,int)" (?GetBits@TMPQBits@@QEAAXIIPEAXH@Z)
storm.lib(FileStream.obj) : error LNK2019: unresolved external symbol __imp_wsprintfA referenced in function "bool __cdecl BaseHttp_Read(struct TFileStream *,unsigned __int64 *,void *,unsigned long)" (?BaseHttp_Read@@YA_NPEAUTFileStream@@@PEA_KPEAXK@Z)

stormlib.dll: fatal error LNK1120: 2 external unsolved

When i try this command on Windows -> luarocks install lua-stormlib STORM_LIBDIR="C:\Program Files (x86)\Lua\5.2\lib"

The contents of the folder "C:\Program Files (x86)\Lua\5.2\lib" ->

• storm.lib
• StormLibRAD.lib

Remove `file:size ()`

The ability to get the file size via the Lua I/O API is done with file:seek ('end'). This also works with StormLib as well. Support of file:size () in lua-stormlib deviates from the expected API.

Luarocks 2.4.4 does not support Git submodules

Until stable Luarocks supports Git submodules (not sure when that will happen) an alternative solution needs to be used. Perhaps simply cloning in the compat-5.3 repository in totality. Or maybe just the necessary source files.

The rockspec was outdated

So, a few changes had been made since the initial upload to Luarocks. However, I did not realize I needed to upload it again. I assume some sort of fancy link between GitHub and Luarocks. This was a mistake. The new rockspec has been uploaded.

Build error on LuaRocks Install

Hello it's me Mario,

Another error :D

C:\Users\iThorgrim>luarocks install lua-stormlib
Installing https://luarocks.org/lua-stormlib-0.2.3-1.src.rock

lua-stormlib 0.2.3-1 depends on lua >= 5.1, < 5.5 (5.1-1 provided by VM)
mingw32-gcc -O2 -c -o src/init.o -IC:\Program Files (x86)\LuaRocks/include src/init.c -Ilib/compat-5.3/c-api -Ilib/stormlib/src
mingw32-gcc -O2 -c -o src/common.o -IC:\Program Files (x86)\LuaRocks/include src/common.c -Ilib/compat-5.3/c-api -Ilib/stormlib/src
mingw32-gcc -O2 -c -o src/file.o -IC:\Program Files (x86)\LuaRocks/include src/file.c -Ilib/compat-5.3/c-api -Ilib/stormlib/src
mingw32-gcc -O2 -c -o src/finder.o -IC:\Program Files (x86)\LuaRocks/include src/finder.c -Ilib/compat-5.3/c-api -Ilib/stormlib/src
mingw32-gcc -O2 -c -o src/handles.o -IC:\Program Files (x86)\LuaRocks/include src/handles.c -Ilib/compat-5.3/c-api -Ilib/stormlib/src
mingw32-gcc -O2 -c -o src/mpq.o -IC:\Program Files (x86)\LuaRocks/include src/mpq.c -Ilib/compat-5.3/c-api -Ilib/stormlib/src
mingw32-gcc -shared -o stormlib.dll src/init.o src/common.o src/file.o src/finder.o src/handles.o src/mpq.o -LC:\Program Files (x86)\LuaRocks\lib -lstorm C:\Program Files (x86)\LuaRocks/lua5.1.dll -lMSVCR80
src/file.o:file.c:(.text+0x203): undefined reference to `SFileCloseFile@4'
src/file.o:file.c:(.text+0x241): undefined reference to `SFileFinishFile@4'
src/file.o:file.c:(.text+0x35d): undefined reference to `SFileWriteFile@16'
src/file.o:file.c:(.text+0x4a4): undefined reference to `SFileSetFilePointer@16'
src/file.o:file.c:(.text+0x5e8): undefined reference to `SFileReadFile@20'
src/file.o:file.c:(.text+0x76a): undefined reference to `SFileReadFile@20'
src/file.o:file.c:(.text+0x90c): undefined reference to `SFileGetFileSize@8'
src/file.o:file.c:(.text+0xd4a): undefined reference to `SFileCreateFile@32'
src/file.o:file.c:(.text+0xd61): undefined reference to `SFileFinishFile@4'
src/file.o:file.c:(.text+0xdab): undefined reference to `SFileOpenFileEx@16'
src/finder.o:finder.c:(.text+0x3b): undefined reference to `SFileFindClose@4'
src/finder.o:finder.c:(.text+0xf8): undefined reference to `SFileFindNextFile@8'
src/finder.o:finder.c:(.text+0x271): undefined reference to `SFileFindFirstFile@16'
src/mpq.o:mpq.c:(.text+0x31): undefined reference to `SFileFindFirstFile@16'
src/mpq.o:mpq.c:(.text+0x60): undefined reference to `SFileFindClose@4'
src/mpq.o:mpq.c:(.text+0x10b): undefined reference to `SFileCloseArchive@4'
src/mpq.o:mpq.c:(.text+0x18a): undefined reference to `SFileCompactArchive@12'
src/mpq.o:mpq.c:(.text+0x213): undefined reference to `SFileRemoveFile@12'
src/mpq.o:mpq.c:(.text+0x2ba): undefined reference to `SFileRenameFile@12'
src/mpq.o:mpq.c:(.text+0x3c9): undefined reference to `SFileGetFileInfo@20'
src/mpq.o:mpq.c:(.text+0x41b): undefined reference to `SFileGetFileInfo@20'
src/mpq.o:mpq.c:(.text+0x4ae): undefined reference to `SFileSetMaxFileCount@8'
src/mpq.o:mpq.c:(.text+0x5eb): undefined reference to `SFileOpenArchive@16'
src/mpq.o:mpq.c:(.text+0x60f): undefined reference to `SFileCloseArchive@4'
src/mpq.o:mpq.c:(.text+0x65c): undefined reference to `SFileOpenArchive@16'
src/mpq.o:mpq.c:(.text+0x6e9): undefined reference to `SFileCreateArchive@16'
collect2.exe: error: ld returned 1 exit status

Error: Build error: Failed compiling module stormlib.dll

Redesign library (0.3)

Perhaps have the C side simply be thin wrappers around Stormlib? Then provide a Lua layer upon that, as necessary? Perhaps for more Lua specific idioms (e.g. as is the case with mpq:files () and Lua patterns). This would primarily be a internal change, and the external API would remain the same, for those who want a more Lua like experience. But, for those who want, it would become possible to ignore this layer and touch Stormlib more directly than it is now.

This would allow tinkering with the Lua side to be a bit easier, perhaps.

Edit:

-- For the library with the existing API, using more Lua idioms.
require ('stormlib')

-- For the thin wrapper library that hits StormLib more directly. Properly
-- using this library will require some bookkeeping, that the public API
-- will already manage.
require ('stormlib.core')