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. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
