Rachael wrote:Thank you - it's fixed.
Nice! :3
Moderator: GZDoom Developers
Rachael wrote:Thank you - it's fixed.
13:56 a4:../gzdoom/gzdoom > git grep fluidsynth.so.
src/sound/mididevices/music_fluidsynth_mididevice.cpp:#define FLUIDSYNTHLIB1 "libfluidsynth.so.1"
Hirogen2 wrote:Some distributions are on libfluidsynth.so.2 already.
Chris wrote:Hirogen2 wrote:Some distributions are on libfluidsynth.so.2 already.
Which distributions?
On Debian, the latest is 1.1.11 in testing and unstable, which is still libfluidsynth.so.1. I can't say I read anything about a breaking ABI change in fluidsynth. Also noteworthy that on Debian, the package is libfluidsynth1. If there was such a version bump, I'd expect a separate libfluidsynth2 package that could be installed side-by-side.
Hirogen2 wrote:While you can have them installed side by side, the old one is, in general, subject to eviction by the package manager, since nothing depends on it. "dlopen" calls do not constitute a hard dependency; only the DT_NEEDED entries in the ELF program header are, i.e. what `ldd /bin/ls` outputs.
Graf Zahl wrote:Why can't this be done in a sane fashion? What's the point of 'dlopen' if the system can delete this stuff at a whim?
Hirogen2 wrote:That would be openSUSE. Now that you mentioned it, I looked at Gentoo and Arch, and am surprised to not find 2.x there yet, because I remember that community to be generally quick. 2.x came out a month ago, Sep 14 2018.
I switched the openSUSE package to just use -DDYN_xxx=OFF so it gets a link rather than dlopen, after which the dependency magic of a Linux distro can do its thing.
Chris wrote:Note that FluidSynth 2.x does not necessarily mean the library becomes libfluidsynth.so.2. The so version follows semantic versioning rules; the major version only changes on breaking ABI changes. The project version may be separate from that (semantic versioning is relatively useful for side-by-side library installs, but kind of dumb for project versioning).
Graf Zahl wrote:What's the point of versioning if the old version cannot be installed if something needs it???
Corrosion wrote:1. About new feature in 'Display Options' menu: Menu Dim. On first start up it was set to -1 and my menu used default/my mod dim color and intensify.
When I moved slider it's minimal position become 0 and menu havent dim at all. So if I want to return default game based (or mod based) dim I haven't another option than switch it to -1 in gzdoom.ini? Would be nice if it has -1 as minimal value for default settings.
wolfmanfp wrote:Menu Dim is not a new feature to GZDoom, and it have always behaved like this. For me, to be exact.
Return to ZDoom (and related) News
Users browsing this forum: No registered users and 1 guest