Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Cacodemon345

(Unofficial) GZDoom on NetBSD x64

Recommended Posts

As I ended up finding pretty much little mention of NetBSD in the forums, I compiled a GZDoom g4.3.3 build for NetBSD 9.0 using the GCC 7.4.0 toolset. I also did this for fun and as an experiment.

Download it here: https://drive.google.com/file/d/1PcNjn-0NKp9yU2e55nOwXvW6MRINC_IS/view?usp=sharing

I built it from the g4.3.3 branch of the GZDoom git, with modifications detailed in the diff file netbsddiff.txt inside the archive. I had to deal with some hiccups while building, so I had to modify the code a little.

You will need libsndfile, GTK 3.0, OpenAL, FluidSynth to run the executable. The diff file is provided for convenience, however it isn't directly patchable.

Changes made:
1. Errors are now printed to the console (as a temporary workaround).
2. <stdarg.h> include has been added to some places to fix compilation (not required in the current master branch since the fix was applied to ZMusic via a PR).
3. The cmath header include has been added to r_draw to fix compilation.
4. The define condition required to include signal.h has been relaxed in the crashcatcher.c; the header file should now be included if either compiling in macOS or in one of the BSD systems.
5. CMakeLists file was modified to explicitly link to the X11 and jemalloc library.

Problems:
1. Double-printing may happen (not still sure).
2. USB mouse will have to be unplugged and replugged when starting GZDoom due to a SDL2 bug causing it to no longer work under NetBSD.
3. Vulkan support is most likely absent.

Note: Tweaking ld.so.conf may or may not be required too.
Note 2: If the executable fails to show a window, try terminating it and then relaunching. Disabling full screen will allow it to launch more often.

Share this post


Link to post

Are you planning to submit your work to NetBSD ports? And the patch to GZDoom upstream? Both will be more sustainable than just sharing a one-off binary compile here on the forums.

Share this post


Link to post
15 minutes ago, fraggle said:

Are you planning to submit your work to NetBSD ports? And the patch to GZDoom upstream? Both will be more sustainable than just sharing a one-off binary compile here on the forums.

The NetBSD ports system typically operates on the principle that it should only work if it is right and if it works, it should work everywhere. Some changes made to the source would also be considered unacceptable to even get into the upstream GZDoom repo, so I am holding off until I can get it to work properly on NetBSD. Some changes also are not needed anymore in the upstream repo.

 

I also need help from other NetBSD users to fix the issues.

Share this post


Link to post

Hey just a heads up:

 

Windows 10 Pro 64bit:

After extracting the 7z archive from your google drive host, the gzdoom binary only shows up as File, without extension..

It doesn't show up as an exe.

 

Is this Linux/Unix based only?

Share this post


Link to post
36 minutes ago, Mr.Rocket said:

Hey just a heads up:

 

Windows 10 Pro 64bit:

After extracting the 7z archive from your google drive host, the gzdoom binary only shows up as File, without extension..

It doesn't show up as an exe.

 

Is this Linux/Unix based only?

 

A quick Google search tells me NetBSD is a Unix-based OS, so it's probably not surprising this doesn't work on Windows 10.

Share this post


Link to post

Changing the __linux__ defines to __unix__ in the i_system.cpp file seems to allow the errors to be displayed again. Will update the binary file later, it is midnight rn.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×