-
Notifications
You must be signed in to change notification settings - Fork 52
Lack of official documentation for creating shared modules #147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
hmmm. firstly in your build script it's not necessary to link your secondly i'm unable to reproduce this on my macOS machine: i get the following output robbie scratch % lua test.lua
Argument from Lua: 42
Result: 43 one thing to be aware of is that since Windows has multiple C ABIs, you should check that both the |
@robbielyman Thanks for the quick response! I'm glad it worked for you, so the code is correct. I just need to find the problem on my side. I'm not very familiar with MSVC and MinGW and can't answer this question. What I think is happening: ziglua links lua.dll I need to write a shared module for version 5.4.1 I have lua-5.4.1 sources. And already compiled.
compile.bat ::
:: Compiles Lua
::
::
:: Set up environment
::
:: Start local variable scope
@SETLOCAL
:: Locate 'vcvarsall.bat'
@IF NOT "%VS120COMNTOOLS%"=="" @SET VSVARSALL=%VS120COMNTOOLS%..\..\VC\vcvarsall.bat
@IF NOT "%VS140COMNTOOLS%"=="" @SET VSVARSALL=%VS140COMNTOOLS%..\..\VC\vcvarsall.bat
@IF "%VSVARSALL%"=="" @GOTO ENDSETUP
:: Identify the target architecture
@IF NOT "%PROCESSOR_ARCHITECTURE%"=="" (
@IF "%PROCESSOR_ARCHITECTURE%"=="x86" @SET ARCH=x86
@IF "%PROCESSOR_ARCHITECTURE%"=="x64" @SET ARCH=x64
@IF "%PROCESSOR_ARCHITECTURE%"=="AMD64" @SET ARCH=amd64
)
@IF "%ARCH%"=="" @GOTO ENDSCRIPT
:: Call the setup script
@CALL "%VSVARSALL%" %ARCH%
@ECHO ON
:ENDSETUP
::
:: Process files
::
:: Move down into 'src'
@PUSHD src
:: Clean up files from previous builds
@IF EXIST *.o @DEL *.o
@IF EXIST *.obj @DEL *.obj
@IF EXIST *.dll @DEL *.dll
@IF EXIST *.exe @DEL *.exe
:: Compile all .c files into .obj
@CL /MD /O2 /c /DLUA_BUILD_AS_DLL *.c
:: Rename two special files
@REN lua.obj lua54.o
@REN luac.obj lua54c.o
:: Link up all the other .objs into a .lib and .dll file
@LINK /DLL /IMPLIB:lua54.lib /OUT:lua54.dll *.obj
:: Link lua into an .exe
@LINK /OUT:lua54.exe lua54.o lua54.lib
:: Create a static .lib
@LIB /OUT:lua54-static.lib *.obj
:: Link luac into an .exe
@LINK /OUT:lua54c.exe lua54c.o lua54-static.lib
:: Move back up out of 'src'
@POPD
:: Copy the library and executable files out from 'src'
@COPY /Y src\lua54.exe lua54.exe
@COPY /Y src\lua54c.exe lua54c.exe
@COPY /Y src\lua54.dll lua54.dll
:ENDSCRIPT
:: End local variable scope
@ENDLOCAL I have worked cpp code that is built using
lualib.cpp // #pragma lets you provide additional information to the compiler
#pragma comment(lib, "user32.lib")
#pragma comment(lib, "kernel32.lib")
#pragma comment(lib, "lua-5.4.1/src/lua54.lib")
#include <windows.h>
#include <stdio.h>
#include <wchar.h>
#include <winuser.h>
#include <rpcndr.h>
#include <sysinfoapi.h>
#include <cstdint>
#include <string>
#include <thread>
#include <iostream>
#include <fstream>
#define LUA_LIB
#define LUA_BUILD_AS_DLL
#include "lua-5.4.1/src/lua.hpp"
...
static struct luaL_Reg InitStruct[] = {
{ "Now", Now },
{ nullptr, nullptr }
};
extern "C" LUALIB_API int luaopen_lualib(lua_State *L) {
luaL_newlib(L, InitStruct);
return 1;
} I want to port module from cpp to zig.
An interpreter that already contains lua54.dll shows a similar error when running
|
I tried using another lua54.exe from
|
If I don't have lua installed globally, where do the sources come from? https://github.com/natecraddock/ziglua/blob/main/build/lua.zig const lua_base_source_files = [_][]const u8{
"src/lapi.c",
"src/lcode.c",
"src/ldebug.c",
"src/ldump.c",
"src/lfunc.c",
"src/lgc.c",
"src/llex.c",
"src/lmem.c",
"src/lobject.c",
"src/lopcodes.c",
"src/lparser.c",
"src/lstate.c",
"src/lstring.c",
"src/ltable.c",
"src/ltm.c",
"src/lundump.c",
"src/lvm.c",
"src/lzio.c",
"src/lauxlib.c",
"src/lbaselib.c",
"src/ldblib.c",
"src/liolib.c",
"src/lmathlib.c",
"src/loslib.c",
"src/ltablib.c",
"src/lstrlib.c",
"src/loadlib.c",
"src/linit.c",
};
const lua_52_source_files = lua_base_source_files ++ [_][]const u8{
"src/ldo.c",
"src/lctype.c",
"src/lbitlib.c",
"src/lcorolib.c",
};
const lua_53_source_files = lua_base_source_files ++ [_][]const u8{
"src/ldo.c",
"src/lctype.c",
"src/lbitlib.c",
"src/lcorolib.c",
"src/lutf8lib.c",
};
const lua_54_source_files = lua_base_source_files ++ [_][]const u8{
"src/ldo.c",
"src/lctype.c",
"src/lcorolib.c",
"src/lutf8lib.c",
}; |
the build.zig.zon has dependencies for each version of Lua that are fetched and compiled into ziglua. |
I got additional information: simple lualib.c #include <windows.h>
#include <stdio.h>
#include <wchar.h>
#include <winuser.h>
#include <rpcndr.h>
#include <sysinfoapi.h>
#define LUA_LIB
#define LUA_BUILD_AS_DLL
#include "lua-5.4.1/src/lua.h"
#include "lua-5.4.1/src/lauxlib.h"
#include "lua-5.4.1/src/luaconf.h"
static int add(lua_State *L) {
int d1 = luaL_checkinteger(L, 1);
lua_pushinteger(L, d1 + 1);
return 1;
}
static const luaL_Reg InitStruct[] = {
{ "add", add },
{ NULL, NULL }
};
// LUALIB_API = __declspec(dllexport)
LUALIB_API int luaopen_lualib(lua_State *L) {
luaL_newlib(L, InitStruct);
return 1;
} build.zig const std = @import("std");
pub fn build(b: *std.Build) !void {
const target = b.standardTargetOptions(.{});
const optimize = b.standardOptimizeOption(.{});
const lualib = b.addSharedLibrary(.{
.name = "lualib",
.target = target,
.optimize = optimize,
});
const flags = [_][]const u8{
"-std=gnu99",
};
lualib.addIncludePath(b.path("./lua-5.4.1/src"));
lualib.addCSourceFile(.{
.file = b.path("lualib.c"),
.flags = &flags,
});
lualib.addObjectFile(b.path("./lua-5.4.1/lua54.lib"));
lualib.linkLibC();
b.installArtifact(lualib);
} Test folder structure:
test.lua local lualib = require("lualib")
local result = lualib.add(42)
print("Result:", result) Result:
I see the difference in dumpbin dont work
works successfully
Does order matter? Can |
we're quickly reaching the edge of my knowledge, but for comparison, here's robbie scratch % nm -g lualib.so
0000000000008068 D ___dso_handle
U ___error
0000000000008068 D __mh_dylib_header
0000000000008088 D __mh_execute_header
U _luaL_checkstack
U _luaL_checkversion_
U _lua_createtable
U _lua_pushcclosure
U _lua_pushinteger
U _lua_setfield
U _lua_settop
U _lua_tointegerx
0000000000000680 T _luaopen_lualib
U _os_unfair_lock_lock
U _os_unfair_lock_unlock
U _pthread_threadid_np
U _write
U dyld_stub_binder |
@robbielyman Thank you for still being with me :)
Unfortunately this information does not help me at all. I managed to remove const std = @import("std");
const zlua = @import("zlua");
const Lua = zlua.Lua;
fn add(L: *Lua) i32 {
const arg = L.toInteger(1) catch 0;
std.debug.print("Argument from Lua: {}\n", .{arg});
L.pushInteger(arg + 1);
return 1;
}
fn module(lua: *Lua) i32 {
const functions = [_]zlua.FnReg{
zlua.FnReg{ .name = "add", .func = zlua.wrap(add) },
};
Lua.newLib(lua, &functions);
return 1;
}
comptime {
_ = zlua.exportFn("lualib", module);
}
pub fn _DllMainCRTStartup() callconv(.winapi) std.os.windows.BOOL {
return std.os.windows.TRUE;
} But it didn't help. Worked DLL from C
nonworking DLL from zig
I don't see any critical difference. This is a dead end... |
I've never tested shared modules on Windows. I'll try to see if I can debug this sometime soon |
I hope the information below helps. Worked DLL from C
nonworking DLL from zig
|
I managed to put together a working example. build.zig const std = @import("std");
pub fn build(b: *std.Build) void {
const target = b.standardTargetOptions(.{});
const zig_mod = b.addSharedLibrary(.{
.name = "lualib",
.root_source_file = b.path("./src/lualib.zig"),
.target = target,
.optimize = .ReleaseFast,
});
zig_mod.linkLibC();
zig_mod.addIncludePath(b.path("./src/lua-5.4.1/src"));
zig_mod.addObjectFile(b.path("./src/lua-5.4.1/src/lua54.lib"));
b.installArtifact(zig_mod);
} lualib.zig const std = @import("std");
pub const c = @cImport({
@cInclude("luaconf.h");
@cInclude("lua.h");
@cInclude("lualib.h");
@cInclude("lauxlib.h");
});
fn add(L: ?*c.lua_State) callconv(.C) c_int {
const arg = c.luaL_checkinteger(L, 1);
std.debug.print("Argument from Lua: {}\n", .{arg});
c.lua_pushinteger(L, arg + 1);
return 1;
}
const lib_fn_reg = [_]c.luaL_Reg{ .{ .name = "add", .func = &add }, c.luaL_Reg{} };
export fn luaopen_lualib(L: ?*c.lua_State) callconv(.C) c_int {
c.luaL_checkversion(L);
c.lua_createtable(L, 0, 1);
c.luaL_setfuncs(L, &lib_fn_reg, 0);
return 1;
} Test folder structure:
As you see I couldn't use |
Interesting. Glad you got it working. It would be nice if you could use ziglua directly though. I got my Windows environment running and I'm debugging this right now. I'll let you know if I can figure it out |
One of the criteria for using ziglua will be the ability to rename the name of the associated library from lua.dll to lua54.dll. Currently the hardcode "lua" is used, this limits my capabilities. I also don't know if 5.4.7 will fit my 5.4.1 environment, it's a potential risk for me. |
i’m sure we’d consider a PR adding more flexibility to that part of the process. it is a bit odd from my perspective to be posting so frequently in the issue tracker of a project you’re not using. |
I think this is a use case ziglua should support so I'm okay with this.
@yiv1 let me make sure I'm understanding correctly. You have your own copy of Lua 5.4.1 that you have compiled. You want to use Ziglua with this version of lua and build a shared module? |
@robbielyman please forgive my confusion. I saw that this library can create shared modules. But I didn't know that it won't work on windows. My wish is to close the task as soon as possible and, if possible, help the ziglua library become better. Of all the libraries, it has the coolest functionality. Now, thanks to you, I have one of the solutions to the task, but it is not as beautiful as your wrapper on zig. I would like to fully use ziglua. What you did should already work, and I know it should work, but I don't understand what the problem is with windows.
I am far from system programming and will try to explain as best I can. In general "yes", and here are some details:
If I can solve this problem with ziglua, I will be able to: |
Probably the reason is that
These methods are not present in the working dll: The working *.lib build does not contain any Changing one line affects the functionality of the dll
Maybe this will fix the problem. My knowledge is not enough to figure it out, but I will try. |
So, part of the problem is solved. This is not a problem Just add flag for
If you add an additional flag, I can check if 5.4.7 is compatible with 5.4.1. Also, the task of linking to |
lua.zig
build.zig
build.zig.zon
zig build
- is running successfully, buttest.lua
Executing the script
Additional information:
Test folder structure:
If i remove
lua.dll
, i gotI'm confusing. What should I do to get the dll to work?
The text was updated successfully, but these errors were encountered: