gzdoom fails to build on OpenBSD

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.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: gzdoom fails to build on OpenBSD

Re: gzdoom fails to build on OpenBSD

by Rachael » Fri Apr 13, 2018 7:03 am

It should be removed. With the addition of LibADL it doesn't work anyway, and honestly there's really no reason to support non-TLS build chains. If their build environments are so hopelessly outdated they can't provide such a basic feature they should be relegated to unsupported status. After all, even OpenBSD finally managed to catch up.

EDIT: Done

Re: gzdoom fails to build on OpenBSD

by _mental_ » Fri Apr 13, 2018 6:51 am

Is "workaround" still needed to make it compile and link? Like I already said, if there is no point to keep, I would remove it.

Re: gzdoom fails to build on OpenBSD

by Rachael » Fri Apr 13, 2018 6:40 am

Some good news:

10 days ago, OpenBSD 6.3 released, and with it, TLS is now supported. The latest 2D_Refactor branch now fully compiles and runs without errors, provided the correct packages are installed.

Re: gzdoom fails to build on OpenBSD

by Wohlstand » Mon Mar 26, 2018 1:34 pm

_mental_ wrote:Where is TLS used exactly? Because if my "workaround" is useless I would like to revert it.
Oh, is that means my libADLMIDI is not buildable under OpenBSD? Seems one another platform I would support... Gotta to set up a VM to polish the stuff...
EDIT: Miss-looked, isn't trouble in my library... However, I'll try to build my stuff just in case that it will work on the OpenBSD.

Re: gzdoom fails to build on OpenBSD

by _mental_ » Mon Mar 26, 2018 8:28 am

Where is TLS used exactly? Because if my "workaround" is useless I would like to revert it.

Re: gzdoom fails to build on OpenBSD

by Rachael » Mon Mar 26, 2018 7:46 am

Yeah, that commit was pretty much made pointless once ADLMIDI got merged in. Since it used TLS and OpenBSD *still* doesn't support it, OpenBSD is screwed.

That sucks for OpenBSD. Maybe someday the devs will join 2018 and improve their operating system to modern standards. Until then, either compile it on FreeBSD first, or stop using OpenBSD entirely, or simply don't expect to play GZDoom on it. ;)

Re: gzdoom fails to build on OpenBSD

by kevans91 » Mon Mar 26, 2018 7:31 am

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

Re: gzdoom fails to build on OpenBSD

by Rachael » Fri Mar 09, 2018 5:56 pm

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.

Re: gzdoom fails to build on OpenBSD

by _mental_ » Fri Mar 09, 2018 2:35 pm

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.

Re: gzdoom fails to build on OpenBSD

by Chris » Fri Mar 09, 2018 2:00 pm

_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).

Re: gzdoom fails to build on OpenBSD

by _mental_ » Fri Mar 09, 2018 4:56 am

Kinda fixed in f5d5430. GZDoom will be built and run fine for now without TLS support but may break in the future.

Re: gzdoom fails to build on OpenBSD

by _mental_ » Mon Mar 05, 2018 9:17 am

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.

Re: gzdoom fails to build on OpenBSD

by Rachael » Mon Mar 05, 2018 9:02 am

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.

Re: gzdoom fails to build on OpenBSD

by _mental_ » Fri Oct 06, 2017 2:49 am

Delete thread_local keyword from vmexec.cpp and vmintern.h files.

Re: gzdoom fails to build on OpenBSD

by zmyrgel » Fri Oct 06, 2017 1:16 am

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.

Top