Linking errors: undefined reference to glBendFunc, glGetError, sincosf, etc.

[AlbertoGP]

I do not paste the error output because it’s just a bunch of “undefined reference to ...” lines, but I can reproduce it and paste it here if needed.

This is on Pop_OS 22.04 LTS, based on Ubuntu 22.04 LTS.

The issue seems to be the order in which the linking is done at line 74 in the Makefile:
@$(LD) $(LDFLAGS) $(OFILES) -o $@ -Wl,-Map=$(@:.elf=.map)
Which expands to:
gcc -Wl,-x -Wl,--gc-sections -lglut -lm -lGL -O3 -g main.o mtx.o shader.o main.frag.o main.vert.o -o veles.elf -Wl,-Map=veles.map

The correct order, as far as I know, is to have the libraries after the object files, like this:
gcc main.o mtx.o shader.o main.frag.o main.vert.o -Wl,-x -Wl,--gc-sections -lGL -lglut -lm -O3 -g -o veles.elf -Wl,-Map=veles.map

I’m preparing the pull request that fixes it in this system, it’s just swapping LDFLAGS and OFILES.

Could this be specific to this system? Does it link correctly in other Linux distributions or with other compilers?

[AlbertoGP]

Additionally, in the Makefile I had to set GLSLANG := glslangValidator instead of glslang, again I do not know whether other distributions use a different name. This is what I got after apt install glslang-tools.

[hackyourlife]

I just fixed it in a slightly more elegant way than in your PR; the glslangValidator problem should also be fixed now. I'm not sure why the original GCC command worked as is on Archlinux though / why it didn't care about the linking order there. Maybe it's just a GCC version difference? I'm developing on Archlinux and glslangValidator is a symlink to glslang there, that's why I used glslang, but since the symlink exists too, I changed it to glslangValidator so it should now work on other distros too.

[AlbertoGP]

You are right, your fix is better.

Thank you very much. I was pleasantly surprised to have it working as advertised, with many programs / libraries I try out it’s an ordeal to compile them.

[Abdull]

I had the same problems like AlbertoGP initially reported in this issue.

With the changes introduced by now ( ad03080 ), I can successfully build the project and run veles on a AMD Framework 13 AMD, Debian 12, KDE under Wayland.

As an aside, I think it would be great to provide sample files in this repositories to compare against the README.md screenshots. E.g. maybe their exists some FLOSS/licence-compatible GBA ROM that could be bundled in this repository or linked to (given a stable link to a bit-identical version). That is because the first file (some MCU's firmware) I test-ran veles on turned out showing a mostly black window/cube, making me falsly believe my build produced an executable with broken graphics.

[hackyourlife]

This re-implementation of veles does something the original veles didn't do: pixel intensity is computed as result = a * pow(x, b) where you can control a and b by right-click-dragging the mouse horizontally/vertically and x is the intensity from the volumetric data. With this you can adjust the "brightness" (a) and "contrast" (b) such that either small values or small differences compared to noise will stand out. You should be able to see something even with your MCU firmware if you adjust these settings (just right-click-drag the mouse until you see something).

About the "is the graphics broken" problem, I could probably add a screenshot of one of the files already contained in the repo, like e.g. one of the png files. I'm also tempted to add info texts about the current settings which would directly tell you that graphics rendering itself isn't broken.

In general, if you have a good idea how to automatically choose a and b for the formula above for any given file such that you see a meaningful plot out of the box, feel free to make a PR for this.