Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

Solene Rapenne  writes:

> timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>
>> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>> 
>> > Jeremie Courreges-Anglas  writes:
>> >
>> >> On Thu, Sep 06 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>> >>
>> >>> Jeremie Courreges-Anglas  writes:
>> >>>
>>  On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>> 
>> > timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>> >
>> >> Solene Rapenne  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.)
>> >>
>> >> I guess you were not convinced by this point?  If you really don't want
>> >> to add those to LIB_DEPENDS, either make sure that gzdoom runs fine
>> >> without them, or also add them to RUN_DEPENDS.  But LIB_DEPENDS would be
>> >> better IMO.
>> >>
>> >
>> > Slowly iterating to proper port :) Fluidsynth is one of the supported midi
>> > players. The game has bunch of other audio backends as well, some of them
>> > built-in like OPL synth but those do not sound very good.
>> >
>> > I'd like the default gzdoom configuration to work, sounds working
>> > and OPL synth playing music. Then the audio could be enhanced by adding
>> > fluidsynth etc. for improving the game audio. I just did a quick test of 
>> > the
>> > current port and indeed the game seems to pick up fluidsynth just fine at 
>> > runtime
>> > so it can be dropped from BUILD_DEPENDS. Still need to check if the other 
>> > libraries
>> > are loaded properly at runtime.
>> >
>>  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.
>> 

Re: [NEW] gzdoom-3.5.0

[Solene Rapenne]

timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> 
> > Jeremie Courreges-Anglas  writes:
> >
> >> On Thu, Sep 06 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> >>
> >>> Jeremie Courreges-Anglas  writes:
> >>>
>  On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> 
> > timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> >
> >> Solene Rapenne  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.)
> >>
> >> I guess you were not convinced by this point?  If you really don't want
> >> to add those to LIB_DEPENDS, either make sure that gzdoom runs fine
> >> without them, or also add them to RUN_DEPENDS.  But LIB_DEPENDS would be
> >> better IMO.
> >>
> >
> > Slowly iterating to proper port :) Fluidsynth is one of the supported midi
> > players. The game has bunch of other audio backends as well, some of them
> > built-in like OPL synth but those do not sound very good.
> >
> > I'd like the default gzdoom configuration to work, sounds working
> > and OPL synth playing music. Then the audio could be enhanced by adding
> > fluidsynth etc. for improving the game audio. I just did a quick test of the
> > current port and indeed the game seems to pick up fluidsynth just fine at 
> > runtime
> > so it can be dropped from BUILD_DEPENDS. Still need to check if the other 
> > libraries
> > are loaded properly at runtime.
> >
>  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.
> 

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

timo.my...@bittivirhe.fi (Timo Myyrä) writes:

> Jeremie Courreges-Anglas  writes:
>
>> On Thu, Sep 06 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>>
>>> Jeremie Courreges-Anglas  writes:
>>>
 On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:

> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>
>> Solene Rapenne  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.)
>>
>> I guess you were not convinced by this point?  If you really don't want
>> to add those to LIB_DEPENDS, either make sure that gzdoom runs fine
>> without them, or also add them to RUN_DEPENDS.  But LIB_DEPENDS would be
>> better IMO.
>>
>
> Slowly iterating to proper port :) Fluidsynth is one of the supported midi
> players. The game has bunch of other audio backends as well, some of them
> built-in like OPL synth but those do not sound very good.
>
> I'd like the default gzdoom configuration to work, sounds working
> and OPL synth playing music. Then the audio could be enhanced by adding
> fluidsynth etc. for improving the game audio. I just did a quick test of the
> current port and indeed the game seems to pick up fluidsynth just fine at 
> runtime
> so it can be dropped from BUILD_DEPENDS. Still need to check if the other 
> libraries
> are loaded properly at runtime.
>
 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.
>>
>> Still looks mostly good.
>>
>> Looks like for the gtk3 libs the build now depends on cmake setting the
>> define, it doesn't seem to be the case for the other dlopen'd libs.
>> Anyway, this looks fine for now but you'll probably have to discuss with
>> upstream.
>>
>> (review aborted, back to 

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

Jeremie Courreges-Anglas  writes:

> On Thu, Sep 06 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>
>> Jeremie Courreges-Anglas  writes:
>>
>>> On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>>>
 timo.my...@bittivirhe.fi (Timo Myyrä) writes:

> Solene Rapenne  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.)
>
> I guess you were not convinced by this point?  If you really don't want
> to add those to LIB_DEPENDS, either make sure that gzdoom runs fine
> without them, or also add them to RUN_DEPENDS.  But LIB_DEPENDS would be
> better IMO.
>

Slowly iterating to proper port :) Fluidsynth is one of the supported midi
players. The game has bunch of other audio backends as well, some of them
built-in like OPL synth but those do not sound very good.

I'd like the default gzdoom configuration to work, sounds working
and OPL synth playing music. Then the audio could be enhanced by adding
fluidsynth etc. for improving the game audio. I just did a quick test of the
current port and indeed the game seems to pick up fluidsynth just fine at 
runtime
so it can be dropped from BUILD_DEPENDS. Still need to check if the other 
libraries
are loaded properly at runtime.

>>> 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.
>
> Still looks mostly good.
>
> Looks like for the gtk3 libs the build now depends on cmake setting the
> define, it doesn't seem to be the case for the other dlopen'd libs.
> Anyway, this looks fine for now but you'll probably have to discuss with
> upstream.
>
> (review aborted, back to $DAYJOB...)

Yeah, the cmake settings are like first stab to just get things rolling. Need to
find proper place where to put those now that those seem to be working as 
intended.

Timo

Re: [NEW] gzdoom-3.5.0

[Jeremie Courreges-Anglas]

On Thu, Sep 06 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> Jeremie Courreges-Anglas  writes:
>
>> On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>>
>>> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>>>
 Solene Rapenne  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.)

I guess you were not convinced by this point?  If you really don't want
to add those to LIB_DEPENDS, either make sure that gzdoom runs fine
without them, or also add them to RUN_DEPENDS.  But LIB_DEPENDS would be
better IMO.

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

Still looks mostly good.

Looks like for the gtk3 libs the build now depends on cmake setting the
define, it doesn't seem to be the case for the other dlopen'd libs.
Anyway, this looks fine for now but you'll probably have to discuss with
upstream.

(review aborted, back to $DAYJOB...)
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

Jeremie Courreges-Anglas  writes:

> On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
>
>> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>>
>>> Solene Rapenne  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

Re: [NEW] gzdoom-3.5.0

[Jeremie Courreges-Anglas]

On Fri, Aug 03 2018, timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>
>> Solene Rapenne  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

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

Hi,

I asked about the slow start up from gzdoom forums. They assume it is caused by
missing shader caches. So I assume it compiles shader caches before starting 
each game
instead of using cached copy. This seems to be related to our mesa3d version
which is bit lagging behind latest versions. 

timo

 writes:


> Yes i experience the same slow starting even when i compiled from
> source without the port, its something i didnt encounter in linux or
> windows using gzdoom, theres something related to openbsd that is
> causing it, but right now i dont have my openbsd install :(
>
>
> 3. Ago 2018 15:03 por sol...@perso.pw :
>
>
>> 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.
>>>
>>> timo
>>
>> Indeed this fixed the sound issue in at least one mod for me. I wonder
>> if you also experience a very slow startup?
>>
>> ok for import

Re: [NEW] gzdoom-3.5.0

[lea.chescotta]

Yes i experience the same slow starting even when i compiled from source 
without the port, its something i didnt encounter in linux or windows using 
gzdoom, theres something related to openbsd that is causing it, but right now i 
dont have my openbsd install :(


3. Ago 2018 15:03 por sol...@perso.pw :


> 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.
>>
>> timo
>
> Indeed this fixed the sound issue in at least one mod for me. I wonder
> if you also experience a very slow startup?
>
> ok for import

Re: [NEW] gzdoom-3.5.0

[Solene Rapenne]

timo.my...@bittivirhe.fi (Timo Myyrä) wrote:
> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> 
> > Solene Rapenne  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.
> 
> timo

Indeed this fixed the sound issue in at least one mod for me. I wonder
if you also experience a very slow startup?

ok for import

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

timo.my...@bittivirhe.fi (Timo Myyrä) writes:

> Solene Rapenne  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.

timo



gzdoom.tar.gz
Description: Binary data

Re: [NEW] gzdoom-3.5.0

[Timo Myyrä]

Solene Rapenne  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

Re: [NEW] gzdoom-3.5.0

[Solene Rapenne]

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

[NEW] gzdoom-3.5.0

[Timo Myyrä]

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



gzdoom.tar.gz
Description: Binary data