Jeremie Courreges-Anglas <j...@wxcvbn.org> writes: > On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote: > >> timo.my...@bittivirhe.fi (Timo Myyrä) writes: >> >>> Solene Rapenne <sol...@perso.pw> writes: >>> >>>> timo.my...@bittivirhe.fi (Timo Myyrä) wrote: >>>> >>>>> Hi, >>>>> >>>>> Here's a updated port for latest gzdoom version. >>>>> Merged the stuff from Solene's port into my old gzdoom port and bumped it >>>>> to >>>>> latest version. Tested on amd64 and quick gameplay test seems to work and >>>>> installing soundfont and tuning the ini file, the fluidsynth playback >>>>> works. >>>>> >>>>> - added patch to fix the fluidsynth library name >>>>> >>>>> - dropped old linker args from Makefile, these don't seem to be needed at >>>>> all >>>>> >>>>> - Added flag to disable GTK dialogs from building so no need for Gtk >>>>> dependency >>>>> >>>>> - fluidsynth is detected at build time so add it as build_depends. At run >>>>> time >>>>> it needs to be installed but gzdoom can use other midi players as well >>>>> so I >>>>> didn't add it to run_depends. >>>>> >>>>> - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage >>>>> and >>>>> finally xmessage to show crash log. >>>>> >>>>> - OpenAL needs to be installed to have audio. >>>>> >>>>> >>>>> Timo >>>> >>>> Your port is way better than the one I submitted last month, good work! >>>> Still >>>> when using mods, I only have music and no other sound, do you have the same >>>> issue? Doom1 and Doom2 runs fine, so it may be related to the mods... >>> >>> I tested Doom One mod and only got sound in menu and no gameplay sounds or >>> music >>> at all. Got bunch of errors in console so I guess the mods are to blame. >>> >>> Timo >> >> Actually its the problem in library loading. There was wrong library names >> for >> libmpg123, libsndfile in the code. I've patched those and the sounds seem to >> work now after quick test. >> >> Updated port attached. > > Here's some late feedback. > > Regarding the patches, I don't think that #ifdef __OpenBSD__ is a good > approach. (For more on this subject, please look at "#ifdef considered > harmful" from Henry Spencer.) Please don't push such patches upstream. > For our needs in ports land, we can just patch and hardcode the use of > the un-versioned .so libs. Ideas for solutions pushable upstream: > a cmake option that controls whether dlopened library names should > contain a version; or just > #ifndef LIBFOO_NAME > #define LIBFOO_NAME "libfoo.so.1" > ... > which would allow downstreams to override the name. > > About the dlopened libraries: I guess it would be good to list them in > LIB_DEPENDS and add the relevant entries to WANTLIB so that gzdoom gets > properly updated when its deps change. (Even if ''make > port-lib-depends-check'' complains about extra libs.) > > On sparc64, I get this from cmake: > > ... > -- Performing Test HAVE_THREAD_LOCAL > -- Performing Test HAVE_THREAD_LOCAL - Failed > CMake Error at src/CMakeLists.txt:408 (message): > C++ compiler doesn't support thread_local storage duration specifier > > COMPILER = base-clang ports-gcc lets the port build and package on > sparc64. > > The rest of the port looks fine.
Ok, here is an another attempt which allows passing the library names to build process and adding the COMPILER flag to Makefile. Timo
gzdoom.tar.gz
Description: Binary data
