Getting this to run on the x86-64 branch of GMod

[Doridian]

I don't expect you to support a branch that is officially beta, but I figured I'd ask anyway if you can suggest any more steps I can try.

So:

• I am using the x86-64-support-sourcesdk branch of garrysmod_common
• I edited ffi.h to rename luaL_setfuncs to luaL_setfuncsx as LuaJIT seems to declare that one now (I also changed references in ffi.c, removing the extraneous definition flat-out makes the module not load at all) Alternatively, linking explicitly against lua_shared.so makes luaL_setfuncs actually work so you can remove the definition from ffi.h entirely This module now loads successfully and produces the ffi global. I can call ffi.cdef and ffi.new etc all without issues.

However, when I try to call even the most basic function like ffi.C.sleep(5) I get a segfault.

I cannot seem to see anything useful in the crashdump, it just exploes somehwere in lua_shared.so I have also tried running the 32-bit version of GMod (srcds) on that branch and that segfaults as well.

If there is additional information that might be useful, let me know.

Crash dump attached. crash.dmp.zip

[Doridian]

It seems luaffifb is so outdated, it crashes even in vanilla lua5.1 now (on exit, I can still call functions fine). With the following patch https://github.com/safrooze/luaffifb/commit/edda43a88a3e57d481c07aa529b3216931ba7a71 it no longer crashes at all on vanilla lua (or even luajit-2.1.0-beta3 which is what GMod claims to use) The fact that it works in vanilla luajit of the same version GMod seems to use makes me even more confused.

[Doridian]

I got something to work in my fork by switching from luaffifb to cffi-lua https://github.com/SpaceAgeMP/gm_ffi The compile process is very ugly right now as cffi-lua uses meson/ninja to compile. If you have suggestions on how to integrate that with premake, that'd be appreciated.

[danielga]

I have changed the FFI library to cffi-lua in the develop branch and it should compile successfully for either x86 and x86-64. I haven't tried it in Garry's Mod, however.

[Doridian]

[ERROR] error loading module 'ffi' from file 'gmsv_ffi_linux64.dll':
        /home/doridian/s/garrysmod/lua/bin/gmsv_ffi_linux64.dll: undefined symbol: ffi_prep_closure_loc
  1. error - [C]:-1
   2. searcher - lua/includes/modules/require.lua:65
    3. require - lua/includes/modules/require.lua:148
     4. unknown - lua/autorun/server/test.lua:2

It seems it is somehow not linking in libffi.

//EDIT: Thanks for working on this so quick, by the way.

[danielga]

I've force-pushed some changes that should fix loading the module. However, I haven't tested the actual functionality of the module.

[Doridian]

The module indeed now loads and works, at least mostly. It however seems that ffi.sizeof does not behave correctly. At least it behaves differently than when I link to my OS's libffi.

ffi.cdef [[
        struct RandomResult { int32_t value; };
        size_t getrandom(void *buf, size_t buflen, unsigned int flags);
]]

randomres = ffi.new("struct RandomResult")
randomresSize = ffi.sizeof(randomres) 

randomresSize is 4 on my compile against the OS lib, but 0 with your lib. asking sizeof of an int32_t variable directly and not inside a struct, it gives 4, which is correct. Am I misunderstanding FFI here or is something wrong?

//EDIT: Same goes for ffi.sizeof("struct RandomResult") which also yields a 0 on your lib while ffi.sizeof("int32_t") yields 4.

[danielga]

I've been stumped at this issue for a while but I just remembered: libffi version. I'm currently locking libffi 3.3 but that might not be your version. Can you tell me yours?

[Doridian]

I've been stumped at this issue for a while but I just remembered: libffi version. I'm currently locking libffi 3.3 but that might not be your version. Can you tell me yours?

doridian@Fennec:~/mods/gm_ffi$ dpkg --list | grep libffi
ii  libffi-dev:amd64                     3.3-4                             amd64        Foreign Function Interface library (development files)
ii  libffi7:amd64                        3.3-4                             amd64        Foreign Function Interface library runtime

Seems that's what I am using as well.

[danielga]

I believe I have fixed the issue. It requires an update of your garrysmod_common copy and of this repo develop branch.

[Doridian]

Now we're back to this with the latest develop branch:

FFI Load        false   lua/autorun/server/random.lua:2: error loading module 'ffi' from file 'gmsv_ffi_linux64.dll':
        /home/doridian/s/garrysmod/lua/bin/gmsv_ffi_linux64.dll: undefined symbol: ffi_prep_types

[danielga]

I had screwed up the fficonfig.h file. It should be fine now.

[danielga]

Somehow, I managed to fix the ffi.sizeof on Windows but not Linux. Back to the drawing board...

[danielga]

I believe I have fixed this final issue and it's fucking stupid. I have a love/hate relationship with software development. The define NDEBUG is causing this bug. Removed it from the cffi-lua project. I'll see if I can make a simple reproducible project to report the bug.

[Doridian]

@danielga I believe from the way you said you removed NDEBUG from the project, that you maybe forgot to push that change to your fork? Because the only change to upstream seems to be a dllimport fix for windows. (And, indeed, sizeof is broken on this repo, current develop branch)

[danielga]

I reverted that change since the issue was fixed upstream and I rebased the git submodule on that.

[Doridian]

Thanks. Okay, this one was my bad. I forgot git pull will tell you that submodules changed but not actually update them. Ensuring they are all updated now has fixed sizeof.

[danielga]

Awesome, closing issue.