[HEAD, Linux, ARM] Zdoom crashes on exit again ...

[vanfanel]

Hi there,

ZDOOM is crashing again on exit on ARM / GNU/Linux on the Raspberry PI3.
Same compiler version, GCC 6.1.0, which built older commits well.
I have tried to debug this, but doing:

cmake .. -DCMAKE_BUILD_TYPE=Debug
make

results in -O3 optimizations, so no way to debug. Any ideas?

[Matt]

which version of zdoom?

[vanfanel]

@Vaecrius: Latest GIT version (HEAD)

[Edward-san]

You're unlucky because currently ZDoom development is on hiatus. You could try GZDoom and see if the problem still persists.

[vanfanel]

You're unlucky because currently ZDoom development is on hiatus. You could try GZDoom and see if the problem still persists.

GZDoom does not work on the Pi, as it needs desktop GL and not GLES, which the Pi supports.
Anyway, what has happened??

[Rachael]

GZDoom does work just fine on the Pi - I tried it myself - but it does not support OpenGL ES (currently - something I do plan to implement in the future). It runs just fine (albeit extremely slow) with MesaGL, though. The problem is likely missing libraries.

If you need a precompiled ARM version of GZDoom to try, I can send you one, but I have no idea what dependencies it will require. It is best to use "+vid_renderer 0" when starting GZDoom, though.

As for the issue, I suspect this is an issue with SDL. Most of my SDL apps do not exit properly until I kill -9 them.

Also - one more thing - I am sorry to say it, but I just don't think Raspbian works well with ZDoom projects. Personally I use Ubuntu Mate. Its repos are updated enough at least to allow GZDoom to fully compile using the instructions provided in the wiki with no issues.

[vanfanel]

@Eruanna: ZDOOM builds fine on the Pi. It's something it's doing on exit and I am almost sure you will find the same problem with your distro on the Pi platform.
I can't debug it because it insists in building a non-debug version. Again, that's not a problem with Raspbian.

As for GZDOOM, does it build without OpenGL libraries?

Also, GLES support (using SDL2 context initialization) would be awesome.

[Rachael]

Ubuntu Mate (ARM) includes OpenGL libraries. There's just no hardware acceleration for them. If the same isn't true for Raspbian - that's an issue with that distro, hence how I criticized it. Don't get me wrong - I can understand perfectly why they don't include it - but that does little to change the fact that on Ubuntu Mate using my Raspberry Pi - it builds perfectly.

I think what you can do is you can add Ubuntu's repos to Raspbian's apt sources - but figuring that out might be a bit of a chore, as well as knowing exactly what libraries you'll need. I can also give you my repo list, if you want, if that may help.

The offer to give you a precompiled ARM binary is still open. As I said, it won't run well unless you enable software rendering manually, though. I did not build in FMOD support and I haven't actually tested if OpenAL works or not with it.

Needless to say - one point I was trying to make in all of this was, I don't know if this issue can actually be fixed. I have issues with SDL apps on RPi - they run just fine, but they do not exit properly.

[Edward-san]

As for GZDOOM, does it build without OpenGL libraries?

Well, not currently, but if Graf agrees, it could be possible to import the NO_GL cmake option from Zandronum, so at least you would only have the sw renderer (I wonder, it would also apply to the sw renderer, which is NO_SWRENDER option, too?).

[Graf Zahl]

GZDoom doesn't require any external GL dependencies. The declarations are all internal and the linking occurs at runtime, so if you start in software mode, no GL code will ever be run at all or even loaded.

[Edward-san]

I don't understand, but CMake errors out if there are no GL libraries ( OPENGL_FOUND check ). Also they appear in the shared library list for the gzdoom executable (`ldd` showed them on Linux for me).

[Graf Zahl]

It can be that this is just a leftover from before I switched to glLoadGen to create the import list. Then again, there may be something in the init code which I haven't written and rarely looked at.

[Edward-san]

Well, I made an experiment and tried to remove the GL code from CMake, I got this linking error when I tried to compile:

Code: Select all

CMakeFiles/zdoom.dir/gl/system/gl_load.c.o: In function `ogl_LoadFunctions':
/home/edward-san/zdoom/gzdoom/trunk/src/gl/system/gl_load.c:(.text+0x85): undefined reference to `glXGetProcAddressARB'
/home/edward-san/zdoom/gzdoom/trunk/src/gl/system/gl_load.c:(.text+0x9f): undefined reference to `glXGetProcAddressARB'
/home/edward-san/zdoom/gzdoom/trunk/src/gl/system/gl_load.c:(.text+0xfc): undefined reference to `glXGetProcAddressARB'
CMakeFiles/zdoom.dir/gl/system/gl_load.c.o: In function `Load_Version_3_3':
/home/edward-san/zdoom/gzdoom/trunk/src/gl/system/gl_load.c:(.text+0x1b9): undefined reference to `glXGetProcAddressARB'
/home/edward-san/zdoom/gzdoom/trunk/src/gl/system/gl_load.c:(.text+0x1d2): undefined reference to `glXGetProcAddressARB'
CMakeFiles/zdoom.dir/gl/system/gl_load.c.o:/home/edward-san/zdoom/gzdoom/trunk/src/gl/system/gl_load.c:(.text+0x1ec): more undefined references to `glXGetProcAddressARB' follow
clang: error: linker command failed with exit code 1 (use -v to see invocation)
src/CMakeFiles/zdoom.dir/build.make:11595: recipe for target 'gzdoom' failed
make[2]: *** [gzdoom] Error 1
CMakeFiles/Makefile2:788: recipe for target 'src/CMakeFiles/zdoom.dir/all' failed

[Graf Zahl]

Hm. I thought it was fully dynamic.

[vanfanel]

@Eruanna: SDL 1.x is (or at least was) broken on the Pi and some apps would missbehave on exit, yes.
That's not the case with SDL2, where everything is working great with stable 2.0.4.
As for a binary, thanks, but I build and report errors (or fix them if I know the code well enough). A binary makes no sense for what I do, as being able to correctly build is the objetive But thanks again for the offer, really.

@Edward-san and Graf: it would be great to have the NO_GL make option working on GZDOOM for now (until GLES support is implemented) if it's about to replace ZDOOM for software rendered Doom.