Thread: Issue trying to load lua libraries

Gotta go to work so won't be able to try anything until I get home nor will I respond often (or at all as the case may be). I returned to my cheat project and started again (with a new name after considering the possibility of others wanting it too) after learning glfw does just create a single window, I then went and downloaded moonnuklear and its assiociated libraries moonglfw and moongl and attempted to use them just as in the example given on the github page (refer to the makefile for those), however my problem is that when lua attempts to load those libraries it fails and exits, I uploaded the makefile the compiled shared libraries (feel free to recompile if you please) and the source files for my little project here:
gasp.zip - Google Drive
Would appreciate whatever help can be given

Found out part of the reason, apparently lua is not loading libraries as the docs describe, hafta look around for info on this phenomenon, and no has nothing to do with paths or missing loadlib function, already tried the basic hacks meant to fix those

Originally Posted by awsdert

Found out part of the reason, apparently lua is not loading libraries as the docs describe, hafta look around for info on this phenomenon, and no has nothing to do with paths or missing loadlib function, already tried the basic hacks meant to fix those

It loads libraries like the docs say in my own code. What do you mean by "lua is not loading libraries as the docs describe"?

Originally Posted by Hodor

It loads libraries like the docs say in my own code. What do you mean by "lua is not loading libraries as the docs describe"?

I mean when it should be loading the moon libraries it just shuts down execution and passes back to gasp like nothing happend, since gasp shuts down after calling the file I've not got any information on why, I least expected lua to call the error handler if it couldn't load it but not even that gets called. Because lua didn't do as described by the docs I thought maybe it's because I'm using the system version of lua and not compiling lua myself so I modified my makefile a bit (and learned a better way of cloning & updating github code in the process) and got as far as this:

Code:

make --no-print-directory
make: Circular moonnuklear.so.o <- moonnuklear.so dependency dropped.
make: Circular moonglfw.so.o <- moonglfw.so dependency dropped.
clang -ldl -lm -L'.' -lgasp-lua -o gasp.elf gasp.c.o
make: Circular moongl.so.o <- moongl.so dependency dropped.
clang -ggdb -D _DEBUG -shared -fPIC -fpic -ldl -lm -L'.' -o libgasp-lua-d.so cloned/lua/lopcodes.c-d.o cloned/lua/ltm.c-d.o cloned/lua/loslib.c-d.o cloned/lua/lctype.c-d.o cloned/lua/lstate.c-d.o cloned/lua/ltablib.c-d.o cloned/lua/ltests.c-d.o cloned/lua/lzio.c-d.o cloned/lua/lparser.c-d.o cloned/lua/llex.c-d.o cloned/lua/ldblib.c-d.o cloned/lua/lvm.c-d.o cloned/lua/lcode.c-d.o cloned/lua/lcorolib.c-d.o cloned/lua/ldump.c-d.o cloned/lua/liolib.c-d.o cloned/lua/ldebug.c-d.o cloned/lua/loadlib.c-d.o cloned/lua/linit.c-d.o cloned/lua/lmathlib.c-d.o cloned/lua/lbaselib.c-d.o cloned/lua/lstring.c-d.o cloned/lua/lutf8lib.c-d.o cloned/lua/lmem.c-d.o cloned/lua/ldo.c-d.o cloned/lua/lauxlib.c-d.o cloned/lua/lobject.c-d.o cloned/lua/lstrlib.c-d.o cloned/lua/lundump.c-d.o cloned/lua/ltable.c-d.o cloned/lua/lapi.c-d.o cloned/lua/lgc.c-d.o cloned/lua/lfunc.c-d.o
clang -ggdb -D _DEBUG -ldl -lm -L'.' -llibgasp-lua-d.so -o gasp-d.elf gasp.c-d.o
/usr/bin/ld: cannot find -llibgasp-lua-d.so
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [makefile:78: gasp-d.elf] Error 1
Compilation failed.

Struggling to see why it keeps producing these library object errors when they are never even referred to at any point in the makefile, the inability to find the library I fixed by just correcting my usage of -l (I forgot about it when I moved the variable across)
Here's a dump of my makefile, if anyone could help me fix that issue as well then that would be great:

Code:

USE_MINGW:=
CC=clang

HAS_DOS:=$(if $(COMSPEC),1,)

IS_WINDOWS:=$(if $(ProgramFiles),1,)
IS_MSDOS:=$(if $(IS_WINDOWS),,$(HAS_DOS))
IS_WIN64:=$(if ${ProgramFiles(x86)},1,)
IS_WIN32:=$(if $(IS_WIN64),,$(IS_WINDOWS))
IS_MACOS:=
IS_LINUX:=$(if $(IS_WINDOWS),,1)
mkdir=$(if $(wildcard $1),,$(shell mkdir $1))
clone=$(if $(wildcard $1),,$(shell cd $2 && git clone https://github.com/$3))
update=$(shell cd $1 && git remote update)
_fetch=$(shell cd $1 && git fetch $2)
fetch=$(if $(call _fetch,$1,--dry-run),$(call _fetch,$1),)

#gasp stands for Gaming Assistive tech for Solo Play
#Wanted a more fun name than just plain cheat and since
#there are people who need to cheat to be able to play
#(for example the elderly or physically challanged)
#I thought to tie in the name to such audience, let's
#see gaming companies find an excuse for exlcuding that
#audience when they eventually find a way to block this :)
gasp_sources=gasp.c
gasp_objects=$(gasp_sources:%=%.o)
gasp_dbgobjs=$(gasp_sources:%=%-d.o)
gasp_exe=gasp.elf
gasp_dbg_exe=gasp-d.elf

all: $(gasp_exe) $(gasp_dbg_exe)

lua_dir=cloned/lua
moongl_dir=cloned/moongl
moonglfw_dir=cloned/moonglfw
moonnuklear_dir=cloned/moonnuklear

$(call mkdir,cloned)
$(call clone,$(lua_dir),cloned,lua/lua)
$(call clone,$(moongl_dir),cloned,stetre/moongl)
$(call clone,$(moonglfw_dir),cloned,stetre/moonglfw)
$(call clone,$(moonnuklear_dir),cloned,stetre/moonnuklear)
$(call fetch,$(lua_dir))
$(call fetch,$(moongl_dir))
$(call fetch,$(moonglfw_dir))
$(call fetch,$(moonnuklear_dir))

lua_src_dir=$(lua_dir)
lua_sources:=$(filter-out $(lua_src_dir)/lua.c $(lua_src_dir)/onelua.c,$(wildcard $(lua_src_dir)/*.c))
lua_objects:=$(lua_sources:%=%.o)
lua_dbgobjs:=$(lua_sources:%=%-d.o)
lua_dll=libgasp-lua.so
lua_dbg=libgasp-lua-d.so

moongl_dll=moongl.so
moongl_src_dir:=$(moongl_dir)/src
moonglfw_dll=moonglfw.so
moonglfw_src_dir:=$(moonglfw_dir)/src
moonnuklear_dll=moonnuklear.so
moonnuklear_src_dir:=$(moonnuklear_dir)/src
bin_flags=-ldl -lm -L'.'
lib_flags=-shared -fPIC -fpic $(bin_flags)
dlls:=moonnuklear.so moonglfw.so moongl.so
inc_flags=-I $(lua_dir) -I $(moonnuklear_dir) -I $(moonglfw_dir) -I $(moongl_dir)
src_flags=-Wall -std=c99 -DLUA_USE_LINUX -DLUA_USE_READLINE
dbg_flags=-ggdb -D _DEBUG

gasp: $(gasp_exe)
	./$(gasp_exe)

$(gasp_exe): $(gasp_objects) $(lua_dll) $(dlls) force
	$(CC) $(bin_flags) -lgasp-lua -o $@ $(gasp_objects)

debug: $(gasp_dbg_exe)
	gede --args ./$(gasp_dbg_exe)

$(gasp_dbg_exe): $(gasp_dbgobjs) $(lua_dbg) $(dlls) force
	$(CC) $(dbg_flags) $(bin_flags) -lgasp-lua-d -o $@ $(gasp_dbgobjs)

$(lua_dll): $(lua_objects)
	$(CC) $(lib_flags) -o $@ $^

$(lua_dbg): $(lua_dbgobjs)
	$(CC) $(dbg_flags) $(lib_flags) -o $@ $^

%.o: %
	$(CC) $(inc_flags) $(src_flags) -o $@ -c $<

%-d.o: %
	$(CC) $(dbg_flags) $(inc_flags) $(src_flags) -o $@ -c $<

force: ;

.PHONY: all gasp debug makefile

You need to write a minimal test case that exhibits the unexpected behaviour. It seems unlikely anybody can help with a code dump of thousands of lines of barely legible uncommented code pulling in a whole bunch of code from different libraries. For a start, though, why is your lua_allocator() function so complicated? It only needs to call realloc() and free() and doesn't need all of that other logic. Lua 5.3 Reference Manual

Originally Posted by Hodor

You need to write a minimal test case that exhibits the unexpected behaviour. It seems unlikely anybody can help with a code dump of thousands of lines of barely legible uncommented code pulling in a whole bunch of code from different libraries. For a start, though, why is your lua_allocator() function so complicated? It only needs to call realloc() and free() and doesn't need all of that other logic. Lua 5.3 Reference Manual

It's using that logic cause I like to be cautious, I tend to reuse functions like that so I just make it so any errors will be passed back to the calling function making it easier to diagnose where the error came from

Edit as for the external libs they're something I was looking through just now with a custom compile, there are some errors so I'll have to look at it more in depth after work or 2mw

Originally Posted by Hodor

But... you don't trust realloc()?

Also, you're not passing any errors back to your functions, you're passing them back to Lua. The function needs to behave exactly how Lua expects and it doesn't seem to be doing that

free(NULL); // This is fine
realloc(NULL, newsize); // This is fine (I know you've said in the past you don't trust this, but you have to. If you can't trust your compiler and std library then you may as well write nothing)

I think you're being over cautious and it's confusing (to me) and it's maybe introducing hard to find bugs. I really don't understand why you're using a custom alloc function at all to be honest... what I mean is, why aren't you simply using luaL_newstate()?

realloc(NULL... has caused me problems before so now I just assume it is unsafe, as for luaL_newstate I didn't even know it existed

Originally Posted by awsdert

[...] as for luaL_newstate I didn't even know it existed

Might be best to use that for now and after the bugs are sorted out then move to using lua_newstate (if you have to)

realloc(NULL, size) is exactly the same as malloc(size). If you used a compiler that treated them differently, then get a new compiler (I know gcc handles it correctly). I use realloc(NULL, size) regularly without issue because it's guaranteed to work, and a compiler that doesn't uphold that guarantee should be taken out back and shot.

(I had a former coworker who didn't trust free(NULL) because some compiler (I think it was the compiler for PalmOS or something) didn't handle it correctly. Shame on that compiler!)