FLTK issues compiling on Ubuntu 14.04

[flamewing]

After fixing up all files to use the system Lua 5.2 development files, compilation still fails with FLTK errors. Several enumeration constants are used in several files are not present in the respective files (here is an error log).

While this is likely a packaging issue in Ubuntu, it would be good to not have Retro Graphics Toolkit depend on those as it prevents successful builds.

[ComputerNerd]

Thank you for reporting this. I was wondering how well Retro Graphics Toolkit would build on other distributions. The reason for this is because I used the source code from FLTK 1.3.3 and those functions were not present in the version you are using. Using the online package list for Ubuntu I noticed that there is a package for FLTK 1.1 and FLTK 1.3.x (for Ubuntu 14.04 it is version 1.3.2). Are you using the 1.3 package? I can regenerate the FLTK bindings using the 1.3.2 source code instead if it turns out that you have 1.3.2 installed or add #ifdef statements.

Also a note regarding Lua. The reason compile Lua locally is due to the fact that I want to take advantage of zero cost exceptions. This is done by compiling Lua via a C++ compiler instead of a C compiler which means the throw keyword is used to exceptions instead of setjmp and longjmp. Retro Graphics Toolkit uses try catch blocks to catch exceptions thrown by the Lua library. Have you already read the compiling instructions here: https://github.com/ComputerNerd/Retro-Graphics-Toolkit/blob/master/INSTALL?

[flamewing]

I am using FLTK 1.3.x, yes. I went thrawling through FLTK documentation before submitting the bug and noticed that there was a lot of stuff added in 1.3.3.

I had read the INSTALL, yes, but I missed that note about zero cost exceptions. I think that this part of the document is a bit misleading: on a first reading, the third paragraph (lines 9-12) implies that the only reason for building Lua like that is because it allows you to test both builds simultaneously. This led me to skip the Lua section and decide to fix up the includes instead. Now that I know better, I see that this is not the intent of that paragraph.

Hm. I seem to recall that, on Windows, Dwarf exceptions are 32-bit only and can't be thrown across DLL boundaries, while SEH is 64-bit only due to patent issues... and they are basically the two methods of zero-overhead exception handling on Windows. Do the exceptions actually work in this case? (though to be fair, the 32-bit case is maybe because most DLLs on Windows aren't Dwarf aware, so the exception unwinding can't go all the way to were it should be caught... meaning the exceptions thrown by Lua could work anyway).

[ComputerNerd]

Thank you for clearing up which version you have installed. As of now the best solution I have is to solve this via means of using the preprocessor to check which version of FLTK is installed. The only disadvantage of this is if someone tries to use a function specific to FLTK 1.3.3 and sends it to someone who has FLTK 1.3.2 installed. This is unlikely to happen and I will add a warning in the documentation about this issue.

I will also edit the INSTALL file. While I am at it I will rename it to COMPILE. I was just trying to follow a convention but now I realize that there is no need to do such.

I have tested throwing an exception via the Lua library using the windows version and it works properly.

[ComputerNerd]

@flamewing this issue should be fixed in commit b9b5983fbc4c3767ee8cf1c44ad732acc866a8db. I am leaving this issue open in case it still will not compile from you.

[flamewing]

Switching to latest Lua as described in INSTALL and using a clean working dir, most of it builds — except for one file (apparently), which gives this error:

g++  -march=native -flto -fuse-linker-plugin -I/usr/include/fltk/ -IautogeneratedBindings/ -I. -Ilua/src -s -Ikens/ -c -O3 -pipe -march=native -fomit-frame-pointer -fno-rtti -std=gnu++11 autogeneratedBindings/FLTK_Fl_Spinner.cpp -o autogeneratedBindings/FLTK_Fl_Spinner.o
autogeneratedBindings/FLTK_Fl_Spinner.cpp: In function ‘int Fl_Lua_Spinner_set_active(lua_State*)’:
autogeneratedBindings/FLTK_Fl_Spinner.cpp:1537:11: error: ‘class Fl_Lua_Spinner’ has no member named ‘set_active’
     self->set_active();
           ^
make: *** [autogeneratedBindings/FLTK_Fl_Spinner.o] Error 1

Looking over the FLTK include files, it seems that set_active was also added in 1.3.3…

[ComputerNerd]

It should be fixed now. I ended up installed FLTK 1.3.2 myself and it now builds.

[flamewing]

Confirmed, compiles, links and executes perfectly fine.

[ComputerNerd]

Almost forgot to mention: Thank you for reporting this issue. I am always interested to see how well Retro Graphics Toolkit builds on other systems.