gzdoom fails to build on OpenBSD

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
zmyrgel
Posts: 8
Joined: Sun Oct 01, 2017 1:05 am

gzdoom fails to build on OpenBSD

Post by zmyrgel »

Hi,

I'm to make gzdoom-g3.1.0 to run on OpenBSD and with a bit of patching, following sample from master branch:
https://github.com/coelckers/gzdoom/com ... dd34810e55

I've got it to compile but it fails when it tries to link gzdoom with following error:

[code][100%] Building CXX object src/CMakeFiles/zdoom.dir/math/fastsin.cpp.o
[100%] Building CXX object src/CMakeFiles/zdoom.dir/zzautozend.cpp.o
[100%] Linking CXX executable ../gzdoom
CMakeFiles/zdoom.dir/b_game.cpp.o: In function `FCajunMaster::SpawnBot(char const*, int)':
/home/tmy/tmp/gzdoom-g3.1.0/src/b_game.cpp:(.text+0xa93): warning: warning: strcat() is almost always misused, please use strlcat()
CMakeFiles/zdoom.dir/d_netinfo.cpp.o: In function `D_WriteUserInfoStrings(int, unsigned char**, bool)':
/home/tmy/tmp/gzdoom-g3.1.0/src/d_netinfo.cpp:(.text+0x3731): warning: warning: sprintf() is often misused, please use snprintf()
CMakeFiles/zdoom.dir/posix/sdl/i_system.cpp.o: In function `I_Error(char const*, ...)':
/home/tmy/tmp/gzdoom-g3.1.0/src/posix/sdl/i_system.cpp:(.text+0x650): warning: warning: vsprintf() is often misused, please use vsnprintf()
CMakeFiles/zdoom.dir/posix/sdl/crashcatcher.c.o: In function `gdb_info':
/home/tmy/tmp/gzdoom-g3.1.0/src/posix/sdl/crashcatcher.c:(.text+0xc72): warning: warning: strcpy() is almost always misused, please use strlcpy()
CMakeFiles/zdoom.dir/tempfiles.cpp.o: In function `FTempFileName::FTempFileName(char const*)':
/home/tmy/tmp/gzdoom-g3.1.0/src/tempfiles.cpp:(.text+0x32): warning: warning: tempnam() possibly used unsafely; consider using mkstemp()
CMakeFiles/zdoom.dir/s_advsound.cpp.o: In function `AAmbientSound::SetTicker(FAmbientSound*)':
/home/tmy/tmp/gzdoom-g3.1.0/src/s_advsound.cpp:(.text+0x6536): warning: warning: rand() may return deterministic values, is that what you want?
CMakeFiles/zdoom.dir/scripting/vm/vmexec.cpp.o: In function `__cxx_global_var_init':
/home/tmy/tmp/gzdoom-g3.1.0/src/scripting/vm/vmexec.cpp:(.text+0x42): undefined reference to `__cxa_thread_atexit'
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error 1 in . (src/CMakeFiles/zdoom.dir/build.make:10917 'gzdoom')
*** Error 1 in . (CMakeFiles/Makefile2:863 'src/CMakeFiles/zdoom.dir/all')
*** Error 1 in /home/tmy/tmp/gzdoom-g3.1.0/build (Makefile:130 'all')
tmy@phobos build $[/code]

I'm using OpenBSD-current and the default compiler is clang 4.0. I also tried to use gcc 4.9 from ports tree and with it, the linking succeeded but running the gzdoom segfaults pointing to TArray destructor so I think thats related to the above __cxa_thread_atexit reference.
Any ideas how to proceed with this?
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: gzdoom fails to build on OpenBSD

Post by _mental_ »

It looks like Clang uses libc++ but links executable without libc++abi. Hard to say for sure without OpenBSD installation.
You can try to run cmake with an additional switch:

Code: Select all

-DCMAKE_EXE_LINKER_FLAGS=-lcxxabi
If this extra switch won't help you need to figure out yourself in which library __cxa_thread_atexit symbol is located.
Clang builds GZDoom just fine on Linux and macOS out of the box so I can only guess what's wrong with it on OpenBSD.

As for crash with GGC compiled executable it's not related to the linking issue above.
Please provide complete call stack of crashed thread from Debug build.
zmyrgel
Posts: 8
Joined: Sun Oct 01, 2017 1:05 am

Re: gzdoom fails to build on OpenBSD

Post by zmyrgel »

I've been trying various combinations but haven't found a method that works.

The function seems to exist in libc++abi

tmy@phobos zdoom $ nm -g /usr/lib/libc++abi.so.0.0 | grep cxa_thread_atexit
00000000 F /usr/src/lib/libcxxabi/src/cxa_thread_atexit.cpp

I added following to ports file of zdoom:
CONFIGURE_ARGS+= -DCMAKE_EXE_LINKER_FLAGS="-lc++abi"

When compiling the port it fails with another set of unresolve references:
/usr/bin/../lib/libc++abi.so.0.0: undefined reference to `pthread_rwlock_rdlock'
/usr/bin/../lib/libc++abi.so.0.0: undefined reference to `pthread_rwlock_unlock'
/usr/bin/../lib/libc++abi.so.0.0: undefined reference to `pthread_rwlock_wrlock'

Those then seem to be in libpthread:
tmy@phobos zdoom $ nm -g /usr/lib/libpthread.so.24.0 | grep pthread_rwlock_rdlock
00002960 T pthread_rwlock_rdlock

I added "-lpthread" before the "-lc++abi" but after compiling it then failed with original "undefined reference to __cxa_thread_atexit" for some reason.

Any ideas?
zmyrgel
Posts: 8
Joined: Sun Oct 01, 2017 1:05 am

Re: gzdoom fails to build on OpenBSD

Post by zmyrgel »

Ah, problem seems to stem that OpenBSD doesn't support Thread Local Storage with C++ yet so hence the link failure. There seems to be work adding it so I'll re-try once the TLS support has landed.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: gzdoom fails to build on OpenBSD

Post by Graf Zahl »

Right now you can just disable the thread local storage because only the main thread can call the VM - but it is not guaranteed that this will remain so forever.

Also, what kind of system does not have such an essential feature...?
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: gzdoom fails to build on OpenBSD

Post by _mental_ »

It's not so uncommon: Xcode before 8.x cannot handle such definition too. TLS is supported of course but it was accessible only via calling designated functions.
zmyrgel
Posts: 8
Joined: Sun Oct 01, 2017 1:05 am

Re: gzdoom fails to build on OpenBSD

Post by zmyrgel »

Graf Zahl wrote:Right now you can just disable the thread local storage because only the main thread can call the VM - but it is not guaranteed that this will remain so forever.

Also, what kind of system does not have such an essential feature...?
Dumb question but how the thread local storage can be disabled? I've looked at the clang and gcc man pages but didn't notice a flag to disable it.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: gzdoom fails to build on OpenBSD

Post by _mental_ »

Delete thread_local keyword from vmexec.cpp and vmintern.h files.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: gzdoom fails to build on OpenBSD

Post by Rachael »

So I've had OpenBSD for a few days and tried this out. It resulted me in creating this commit, based on _mental_'s suggestion. I didn't push this to master because I know littering the code with system-specific directives, especially when it's due to lack of support that may be added later, is frowned upon. But nevertheless, it works.

Strangely, even FreeBSD didn't choke on this bit, although I'll grant that FreeBSD is FAR less conservative of an operating system than OpenBSD is.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: gzdoom fails to build on OpenBSD

Post by _mental_ »

Lack of thread_local support needs to be evaluated in CMake and preprocessor definition used in code should be set to nothing or thread_local depending on result.
Honestly it's a complication for nothing. Let's someone really interested in OpenBSD support do a PR for this.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: gzdoom fails to build on OpenBSD

Post by _mental_ »

Kinda fixed in f5d5430. GZDoom will be built and run fine for now without TLS support but may break in the future.
User avatar
Chris
Posts: 2940
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: gzdoom fails to build on OpenBSD

Post by Chris »

_mental_ wrote:Kinda fixed in f5d5430. GZDoom will be built and run fine for now without TLS support but may break in the future.
Is that a good idea? That's just laying a time-bomb for a bug to occur without warning (i.e. when thread_local actually needs to do something, it silently won't on OpenBSD leading to undefined behavior, and someone will have to pick through the code to realize thread_local is quietly a no-op if it's unsupported).
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: gzdoom fails to build on OpenBSD

Post by _mental_ »

Currently it doesn’t matter if VM stack is defined thread_local or not. Storage class TLS isn’t used anywhere else.
Of course if we will start to use it the “workaround” needs to be removed.
Also, warning is shown during CMake configuration. It’s up to user to look at it and to figure out what to do with it.
Complicating code with function based TLS like pthread_?etspecific() is certainly out of scope. I would better revert the “workaround” and set topic flag back to Can’t Fix.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: gzdoom fails to build on OpenBSD

Post by Rachael »

When it breaks, just change the redefinition from a warning to an actual error and remove the redefinition?

This is just a stopgap to get an OpenBSD build working. Though using OpenBSD for gaming is a pretty crazy idea, if you ask my opinion. FreeBSD is a lot more flexible, if you must use a BSD based operating system. I've heard NetBSD is a lot worse but I haven't tried it yet, so I can neither confirm nor deny this.

Gaming or not though - it's pretty bad that OpenBSD does not yet have this feature, because I believe that it could be critical in server applications. But since web servers seem to work without it, probably nobody cares.
kevans91
Posts: 72
Joined: Tue Sep 16, 2014 11:25 am

Re: gzdoom fails to build on OpenBSD

Post by kevans91 »

Rachael wrote:So I've had OpenBSD for a few days and tried this out. It resulted me in creating this commit, based on _mental_'s suggestion. I didn't push this to master because I know littering the code with system-specific directives, especially when it's due to lack of support that may be added later, is frowned upon. But nevertheless, it works.

Strangely, even FreeBSD didn't choke on this bit, although I'll grant that FreeBSD is FAR less conservative of an operating system than OpenBSD is.
(Sorry for basically necro'ing)

FreeBSD actually did choke on this bit until r303795 [1]. =) Our gzdoom port won't build as-is on FreeBSD < 10.4 because of this along with the fact that I didn't want to hack around it with patches.

[1] https://svnweb.freebsd.org/base/?view=r ... on=r303795
Post Reply

Return to “Closed Bugs [GZDoom]”