Compile time issues

[awsdert]

Been trying to compile moongl, moonglfw and moonnuklear (after having given up on glut) with into my own (so I can follow full debug stack) and a number of errors popped up (the first lot I forgot to note down but were relatively easy to fix) but now I've gotten stuck at this point:

make --no-print-directory
clang -I cloned/lua -I cloned/moonnuklear -I cloned/moonglfw -I cloned/moongl -Wall -std=c99 -DLUA_USE_LINUX -DLUA_USE_READLINE -DLINUX -o cloned/moonglfw/src/utils.c.o -c cloned/moonglfw/src/utils.c
cloned/moonglfw/src/utils.c:345:28: warning: declaration of 'struct timespec' will not be visible outside of this function [-Wvisibility]
static void sectots(struct timespec *ts, double seconds)
                           ^
cloned/moonglfw/src/utils.c:347:7: error: incomplete definition of type 'struct timespec'
    ts->tv_sec=(time_t)seconds;
    ~~^
cloned/moonglfw/src/utils.c:345:28: note: forward declaration of 'struct timespec'
static void sectots(struct timespec *ts, double seconds)
                           ^
cloned/moonglfw/src/utils.c:348:7: error: incomplete definition of type 'struct timespec'
    ts->tv_nsec=(long)((seconds-((double)ts->tv_sec))*1.0e9);
    ~~^
cloned/moonglfw/src/utils.c:345:28: note: forward declaration of 'struct timespec'
static void sectots(struct timespec *ts, double seconds)
                           ^
cloned/moonglfw/src/utils.c:348:44: error: incomplete definition of type 'struct timespec'
    ts->tv_nsec=(long)((seconds-((double)ts->tv_sec))*1.0e9);
                                         ~~^
cloned/moonglfw/src/utils.c:345:28: note: forward declaration of 'struct timespec'
static void sectots(struct timespec *ts, double seconds)
                           ^
cloned/moonglfw/src/utils.c:359:20: error: variable has incomplete type 'struct timeval'
    struct timeval tv;
                   ^
cloned/moonglfw/src/utils.c:359:12: note: forward declaration of 'struct timeval'
    struct timeval tv;
           ^
cloned/moonglfw/src/utils.c:360:8: warning: implicit declaration of function 'gettimeofday' is invalid in C99 [-Wimplicit-function-declaration]
    if(gettimeofday(&tv, NULL) != 0)
       ^
cloned/moonglfw/src/utils.c:383:5: warning: implicit declaration of function 'usleep' is invalid in C99 [-Wimplicit-function-declaration]
    usleep((useconds_t)(seconds*1.0e6));
    ^
cloned/moonglfw/src/utils.c:383:13: error: use of undeclared identifier 'useconds_t'
    usleep((useconds_t)(seconds*1.0e6));
            ^
3 warnings and 5 errors generated.
make: *** [makefile:121: cloned/moonglfw/src/utils.c.o] Error 1
Compilation failed.

[stetre]

Are you using the makefile included in the projects or what else?

[awsdert]

When I compiled it normally yeah, but some issue cropped up in my project where I couldn't load the libraries despite using your example backend files so I'm trying to compile a debug bug build and see what happend, unfortunatly your makefile doesn't seem to have a debug target so I decided that rather than fiddle with the original I would do a wildcard search on the src directory and compile everything under the same flags as my project and the flags I give lua, lua compiled without issue (once I gave the correct defines) but I'm struggling to fully compile yours and I'm thinking that perhaps this has something to do with why I couldn't load it, either way I need to be able to follow the full stack when issues crop up to see what happened so I can diagnose the source of whatever issue I find (otherwise sometimes it's just blindly fumbling around until I fix it)

[stetre]

Can you please report the issues you had when loading the libraries built with their original makefiles? Or when building them with the original makefiles? I can't debug a customized build system I do not have access to.

[awsdert]

Ran this:

make --no-print-directory moon_libs_original
cd cloned/moongl && make
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o getuniform.o getuniform.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o pipeline.o pipeline.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o enums.o enums.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o getvertex.o getvertex.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o transform.o transform.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o query.o query.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o sync.o sync.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o renderbuffer.o renderbuffer.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o texture.o texture.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o perfragment.o perfragment.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o init.o init.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o framebuffer.o framebuffer.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o object.o object.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o nongl.o nongl.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o uniform.o uniform.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o subroutine.o subroutine.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o draw.o draw.c
draw.c: In function ‘MultiDrawElementsBaseVertex’:
draw.c:282:54: warning: passing argument 4 of ‘__glewMultiDrawElementsBaseVertex’ from incompatible pointer type [-Wincompatible-pointer-types]
  282 |     glMultiDrawElementsBaseVertex(mode, count, type, (const void* const*)indices, drawcount,basevertex);
      |                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                      |
      |                                                      const void * const*
draw.c:282:54: note: expected ‘void **’ but argument is of type ‘const void * const*’
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o bitfield.o bitfield.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o pixel.o pixel.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o utils.o utils.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o proginterface.o proginterface.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o sampler.o sampler.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o capabilities.o capabilities.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o vertex_array.o vertex_array.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o hint.o hint.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o main.o main.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o buffer.o buffer.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o getstring.o getstring.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o whole_framebuffer.o whole_framebuffer.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o program.o program.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o debug.o debug.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o teximage.o teximage.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o raster.o raster.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o getintformat.o getintformat.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o get.o get.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o func.o func.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include -I/usr/include/lua5.3 -I/usr/local/include/lua5.3   -c -o shader.o shader.c
cd cloned/moonglfw && make
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o enums.o enums.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o hint.o hint.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o window.o window.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o callbacks.o callbacks.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o vulkan.o vulkan.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o id.o id.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o monitor.o monitor.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o win.o win.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o mon.o mon.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o native.o native.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o context.o context.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o getproc.o getproc.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o main.o main.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o input.o input.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o cur.o cur.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I/usr/include/lua5.3   -c -o utils.o utils.c
cd cloned/moonnuklear && make
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o enums.o enums.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o image.o image.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o panel.o panel.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o flags.o flags.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o nuklear.o nuklear.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o layout.o layout.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o window.o window.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o cursor.o cursor.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o objects.o objects.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o atlas.o atlas.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o versions.o versions.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o utils.o utils.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o context.o context.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o main.o main.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o edit.o edit.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o buffer.o buffer.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o font.o font.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o widgets.o widgets.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o input.o input.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o tracing.o tracing.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o canvas.o canvas.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o structs.o structs.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o udata.o udata.c
cc -O2 -Wall -Wextra -Wpedantic -std=gnu99 -DLUAVER=5.3 -fpic -DLINUX -I./nuklear -I/usr/include/lua5.3   -c -o style.o style.c
Compilation finished successfully.

There may be some missing messages since I've already corrected a few mistakes before it occured to me to post about the errors I was getting

[awsdert]

The main difference I can see is that I used the -std=c99 flag while you used -std=gnu99

[stetre]

You should try with fresh clones then. However, I see that the compilation succeeded, apart from that warning that you can ignore (it may depend on the version of GLEW you have on your system: that argument type is correct, as you can check in the OpenGL manual page for the glMultiDrawElementsBaseVertex function).

Now try installing the three libraries somewhere, run the examples to see if they work, and let me know if they produce some errors.

If you install the libraries in the default location usr/local, then Lua will find them at runtime without having to set the LUA_PATH and LUA_CPATH variables. If you don't want (or can not) install them there, then follow these instructions (the instructions use moonfltk as example, but moongl, moonglfw, etc. are supposed to work in the same way).

[awsdert]

Well I tried that and doesn't seem to have complained about missing object files at the end, some issues I managed to resolve by including extra headers (sys/time.h and sys/types.h) but the implicit usleep error wouldn't go away until I shoved this in:

#elif (_BSD_SOURCE) ||\
    ((_XOPEN_SOURCE) >= 500 ||\
        (_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED)) &&\
    !((_POSIX_C_SOURCE) >= 200809L || (_XOPEN_SOURCE) >= 700)
    usleep((useconds_t)(seconds*1.0e6));
#else
    sleep(seconds);
#endif

Still getting the warnings, tried looking through the headers and code to see if anything was not closed properly or closed too early but didn't find anything, would still like to compile in c99 without warnings instead of gnu99 for sake of portability so can you try compiling yours under the c99 witch instead and resolve what errors you can please (I'm sure when I get a hold of the changes you've made it will resolve majority of my issues), in mean time I'm gonna test some other code for what I was originally intending to do with a GUI, really don't want to rely on ncurses by default, rather leave that as a fallback, I'll also have too look for a lua mapping for that too ⎢⎢⎢⎻_⎻

[stetre]

Is it to address some specific problem that you want to use c99 instead of gnu99, or is it just for a generic 'sake of portability'?

[awsdert]

generic sake of portability, it's fine to treat the gnu specific as extensions to the library but where possible one should keep to portable code especially when the library relies on opengl for backend stuff

[stetre]

May I ask why? I mean, what has OpenGL to do with this and how is it affected? Just curious.

BTW, the libraries are not that far away from c99 compatibility, since they just use a few POSIX calls here and there mainly for time-related stuff. I should investigate better but, honestly, I'd rather address issues when they reveal themselves to be really issues. Are you foreseeing to use platforms where gnu99 is not an option?

[awsdert]

Correct, I'm trying to write my project in way that allows porting to say windows or osx, normally I use IUP from tegraf for my GUI stuff but for some reason that is unable to compile on the system I'm on, would use ogre but that's in c++ with no c api, I would've excepted a library that uses c++ as an extension to a c api but from what I've seen that's not done in ogre or many other GUI libaries I've looked into so now I'm trying a combination of opengl, glfw and nuklear which all use a c api and since you've already done the hard work of plugging in everything to lua I figured it made more sense to rely on your library and just code from there. Ah btw the project I'm working on is something like a basic version of cheat engine for linux, getting impatient with PINCE and GameConqueror looks like it will never support what I want so just gonna do it myself in full C/Lua, don't really care about matching the cheat engine api though since it's a new project why not just let peops play with their own ideas and fob off whatever I can to external libraries like yours

[stetre]

As far as I know, these libraries already work both on Windows (building them with MSYS2) and on OSX. I've not tried them on OSX myself, but some time ago a user did and claimed they work fine. I don't know the current status of OpenGL on OSX, though (I read that Apple has deprecated it on its systems...).

If you use them in the canonical way, i.e. build and install them as they are, and then in your project require() them from Lua code as in the examples, I don't expect gnu99 to be an issue.

[awsdert]

er yeah about that, the whole reason I started trying to compile manually is because they refuse to load, something about moongl.make being missing or something, didn't get to see it's attempt on moonglfw

[stetre]

That may be caused by the LUA_PATH variable not being properly set. Could you try again and report here the exact error? For example, try running demo.lua in moonnuklear/examples.

[awsdert]

Found a hack for now

win32_defines=_WIN32
linux_defines=_GNU_SOURCE LINUX LUA_USE_LINUX LUA_USE_READLINE
defines:=$(if $(IS_LINUX),$(linux_defines),$(win32_defines))

I think you should implement a common header that checks for system defines and then defines anything that ought to have been defined before including anything else, I will point out that my end goal is compiling under c89 full ansi if possible so if you can make your library do the same that would be great, not gonna hold out on that one though, anyways I'll try the GUI again once I fix a separate issue in my own code

[stetre]

May I ask you again why do you impose yourself such a strict requirement? Even Lua itself, which claims to have ANSI C as its "platform", by default compiles with gnu99 and avoids to include so-called "batteries" precisely to meet that requirement (implying that it's a reasonable requirement for the core lua library, but not for extension libraries).

[awsdert]

simply because its the most portable version of C there is, not to say that the default can't be c99 or gnu99 or other flavors, its merely providing the option, also if I remember rightly until the recently microsoft visual c didn't support c99 anyways so in order to support to a degree those older variants I'd like to be able to compile under c89 even if the api has to be trimmed down in that circumstance

[stetre]

Are you sure you are not confusing "being able to compile everywhere" with "portability"? They are not the same thing.

Again, take core Lua as an example of library that provides that option. It does so for a good reason and accepting to pay a price. The good reason is not a mere "sake of portability" or "being able to compile everywhere" (which are not reasons at all, let alone good ones) but because it is meant to be used - and is actually used - on a variety of systems including embedded ones, where you can only expect ANSI C. The price it accept to pay is not being allowed to implement any feature that can not be implemented using only what ANSI C provides (with the only exception of library loading, if I recall correctly). The assumption is that the task of implementing any such additional feature, when needed, is left to external "batteries" such as LuaSocket and these ones we are talking about, precisely because they are not expected to have such a strict requirement. To extend the requirement to batteries you need good reasons. Do you have any?

[awsdert]

Well since my project is for cheating on games and is being writ with portability in mind its likely there will be fellows who want to port it to platforms like dos, the bits that need system api's would be the extension, in the case of dos opengl would be swapped out with ncurses or something and the module would be loaded in lua normally just with a seperate gui handler eg.

if dofile('glGUI') == false then
    dofile('shGUI')
end

[stetre]

In such case you wouldn't need to compile the libraries you don't use, but only their replacements for the particular platform, and from within your project you would load one or the other depending on which you discover being available, which you can do at runtime.

For example, say that in addition to moonnuklear on the platforms where it is available, you have a 'luancurses' binding library to ncurses on DOS, and a 'luawhatevergui' library available on another platform. In your project you could do something like:

local nk, nc, wg
nk = pcall(require, 'moonnuklear')
if not nk then -- not available here, try ncurses:
   nc = pcall(require, 'luancurses')
   if not nc then -- not available here, try whatever GUI:
      wg = pcall(require, 'luawhatevergui')
      if not wg then
         error("cannot find any GUI library")
      end
   end
end
-- ... use the available one among nk, ng, and wg ...

`

[stetre]

PS: The above example code is wrong because pcall returns a boolean followed by either the library table or an error message. I just scratched it down in a hurry, but I hope the point is clear nonetheless: you don't need to be able compile all the alternatives on all the platforms, you just need (at least) one of them for each platform.

[awsdert]

I'm only tried to compile the libraries myself because of a need for debugging ability so I can trace errors back to their source, also because lua wouldn't load one or more of your librabries and I'm trying to diagnose if that is a fault of mine or yours which needs a complete stack tree to see what actually happens when it fails, had it succeeded I wouldn't even thought to manually compile them, either way I think if I can get the my project to run successfully and cheat on ffxv like I originally intended then the project itself should bring more attention to your project when peops decide it's lacking something on the GUI abilities

[stetre]

What has c99 to do with this? Can't you just use gnu99 with the proper flags for debugging? But before diving into the debugger, why don't you report the error(s) you get? Most times error messages and reasoning are enough to find the cause of a library not loading, or at least to delineate the problem.

[awsdert]

Well I figured if I'm gonna include it in my makefile I might as well go for a standard all modern compilers are supposed to support by now, as for not reporting the error yet I wanted to check if it was a problem with my code first, haven't yet plugged anything into lua yet but I did just dump the example files you gave in your repository and copied over the .so files to see if I could get a GUI using code you already confirmed to work at one point, the .so files are indeed found but lua complains of something being missing, here's an output from what I just ran now (using official libs):

make --no-print-directory
Already up to date.
Already up to date.
Already up to date.
Already up to date.
clang -fPIC -ldl -lm -llua -o gasp.elf gasp.c.o
./gasp.elf
Opening backend...
Loading moongl...
Failed:
[string "require('moongl.make')"]:1: module 'moongl.make' not found:
    no field package.preload['moongl.make']
    no file '/usr/share/lua/5.3/moongl/make.lua'
    no file '/usr/share/lua/5.3/moongl/make/init.lua'
    no file '/usr/lib/lua/5.3/moongl/make.lua'
    no file '/usr/lib/lua/5.3/moongl/make/init.lua'
    no file './moongl/make.lua'
    no file './moongl/make/init.lua'
    no file '/usr/lib/lua/5.3/moongl/make.so'
    no file '/usr/lib/lua/5.3/loadall.so'
    no file './moongl/make.so'
    no module 'moongl.make' in file './moongl.so'
main Error: 0x00000016, System Description 'Invalid argument', Process Description 'Test failed'
make: *** [makefile:112: gasp] Error 1
Compilation failed.

[awsdert]

Ignore that invalid argument at bottom, that's separate issue in my own code

[stetre]

Ok. This is a typical error you may encounter when loading Lua modules. A debugger won't help here. The message simply tells you that either the module is missing, or the path to the module is not in the package.path or the package.cpath variables, so the Lua interpreter can not find it.

You should be able to solve the problem by following these instructions (as I already suggested 2 days ago, by the way...)

[awsdert]

DIdn't I say I don't want to install? I tried this at least:

setenv("LUA_PATH","./?.lua",0);
setenv("LUA_CPATH","./?.so",0);

But no change to the lack of module inside the library

[awsdert]

Take a look at this line from my earlier post:

no module 'moongl.make' in file './moongl.so'

Please tell me in what way that indicates to you that this is a problem with the path or cpath variables?

[stetre]

"Install" here means nothing else that copying the .so and .lua files into a location where the Lua interpreter can find them. There is nothing special to it, it's just copying them from the source directory into a more convenient directory. You can as well "install" them into a subdirectory of your project, if you want to. I highly suggest you to choose an install directory and install all the modules there, so to have only one path to add to LUA_PATH and one to LUA_CPATH.

To clarify your ideas, try installing in PREFIX=/tmp/local, for example, and then go to that location and see what is "installed" (e.g. enter the /tmp/local directory and run the tree command there).

About moongl/make.lua: this is a Lua script that is loaded by moongl.so when from the application you execute gl = require("moongl"). MoonGL, like most of my libraries, is mostly implemented in C, but a few parts are implemented directly in Lua, because it is more convenient. That is, the module is composed of a shared object (.so) and a few Lua scripts (.lua) which the Lua interpreter must be able to find at runtime.

[stetre]

That said, if you are developing a project that depends on third-party Lua modules, or if you want to write Lua modules yourself, I highly recommend you to find some time to familiarize on how Lua's require() works: if and how LUA_PATH and LUA_CPATH must be set, the standard package library, etc. Really. You can find all this info in the Lua manual.

(Especially if you plan to release your project, it is very likely that some of your users will report problems on this matter. Even if you strive to keep things simple, stick to standard practices, and make your efforts to document things as clearly as you can, you'll always find some user that'll run into self-inflicted problems and will thus demand your support. Trust me, I speak by experience ;-) ).

[awsdert]

Well I will look into that after getting this to work in a portable manner but thank you for clearing up that issue with the missing make for me, I'll have a look in the repository when I get home to see if it's there, copy that, and check I can get a GUI before I start experimenting on that end

[stetre]

Ok.

(BTW, if you find a more portable way than putting the modules in the standard location where Lua looks for them, let me know.)