Loading example module broken on linux

[i9900]

Silly that you even have to rename the .so to a .dll for it to even find the module which is a bug of its own. It finds the module but then presents me with this error:

Module name: gmcl_example_linux.dll

[ERROR] addons/mca/lua/autorun/client/cl_test.lua:4: Couldn't load module library!
  1. require - [C]:-1
   2. unknown - addons/mca/lua/autorun/client/cl_test.lua:4

The file is not found using gmcl_example_linux.so Same with development branch.

[willox]

Did you compile the module on the same machine you are running it on?

[i9900]

Yes

luarocks | 2.4.2+dfsg-1 |
make |  4.2.1-1.2 |
g++ |  4:8.3.0-1 | 

[willox]

I suggest you try debugging this using the LD_DEBUG environmental variable. You can run something like export LD_DEBUG=all before launching the client through your terminal.

The error message you're getting suggests the binary was either not found or failed to load before any of our API would be involved.

What branch of the game are you running on?

[neico]

Bitness can also be a reason for it not to be found, x86 modules won't work with x64 and vice versa. So make sure you run the correct gmod binary in accordance to it as there's no 32/ 64 prefix/suffix for modules (which really should be a thing as long as both architectures coexist, I'd suggest merely adding 64 after the gm(sv|cl) prefix: gm(sv|cl)64 for best compatibility, see below why I didn't suggest it being after the OS identifier)

But yes, all modules having the same extension always bothered me to no end, I assume laziness on garry's part when writing the parser. It really should be fixed some day to be dll for windows, so for linux and dylib for mac, that way you could remove the OS suffix in the files directly and detect it by file extension only. One could even support the old dll variant for backwards compatibility as a secondary check for the other 2 OSes.

You can check bitness by using file <path to module>

[willox]

we're already using the following formats

_osx.dll
_osx64.dll
_linux.dll
_linux64.dll
_win32.dll
_win64.dll

Yep using the dll extension is weird, but it's what we are already using.

[i9900]

I suggest you try debugging this using the LD_DEBUG environmental variable. You can run something like export LD_DEBUG=all before launching the client through your terminal.

The error message you're getting suggests the binary was either not found or failed to load before any of our API would be involved.

What branch of the game are you running on?

Managed to get the module loaded by installing gcc-multilib and compiling with for 32bit with -m32 flags. However as soon as I tried to add zlib to my project the module wont load again. I'm not doing anything complicated it should not be this difficult. My guess as its trying to find a zlib.so or something like that. The LD_DEBUG does not let me launch the game it complains that client.so is missing. If that worked I'd likely be much closer to finishing this.

Edit: This was an issue of compiling a 32bit module having 64bit libraries on my machine. Along side of the odd naming convention made for extra confusion.