Build fails on 1466 (commit c89faf3) about squeezelite HOT 15 CLOSED

I'm waiting for flac maintainers to have a look. I talked to them already but they say they are are very busy. The PR is just pending.

from squeezelite.

No, it can only be done inside flac, it's deep inside there. I'll increment the version in my PR and use that to verify

from squeezelite.

That #208 should do, at least for all dynamic load case and static cases in Linux. I don't have much possibility to check currently.

from squeezelite.

You can download the patch that we use from SF https://sourceforge.net/projects/lmsclients/files/source/flac.patch/download and apply it to a local build of libflac 1.4.3 and build a local copy.

from squeezelite.

Will this libflac patch be upstreamed?

from squeezelite.

Thanks. I guess I’ll wait and see how that goes. I maintain the squeezelite package for nixpkgs, but I’m hesitant to propose patching libflac for everyone.

from squeezelite.

I understand but you can have a look at the patch, it is not activated unless a libflac API is called. Otherwise, it's the same code that runs, a Boolean prevents any new code from being activated.

from squeezelite.

So a feature was merged into Squeezelite which uses a function in libFLAC which is not part of (upstream) libFLAC, but just a pending PR without any ETA? This seems odd 😄.

I mean doesn't it make more sense to have this functionality within Squeezelite source code, at least until it gets merged into libFLAC? Even then, the time it takes before it tickles down to downstream distribution versions of libFLAC can be years.

We provide DEB packages for recent Squeezelite on Debian Bullseye til Trixie for all architectures. For this to work now, we'd need to patch, compiled and ship own versions of libFLAC, overwriting Debian's libflac package for end users (which can cause conflicts with other software), as well as libflac-dev/headers for our build scripts/systems, maintaining this for all Debian versions and all architectures, which is actually above our possible time and efforts.

FLAC support in Squeezelite is not optional, so there is no way to work around this by disabling FLAC functionality.

The only thing I can practically do now is providing Squeezelite versions before this commit, and I see no real chance to change something about this until all Debian versions we support provide libFLAC versions which have the future of this commit included. This of course breaks the whole purpose of our packages, since Debian itself provides Squeezelite packages, just outdated ones.

Let me know if I understood something wrong, of when someone has an idea how we can practically deal better with this.

from squeezelite.

I can provide a PR so that this function is disabled, but that means no proper support for OggFlac radio for squeezelite, per what you say, for years

from squeezelite.

There is no way to implement this functionality within Squeezelite source code?

Else, the proper solution would be probably to make it optional, yes, and in case enable it automatically if the used function is actually present in the libFLAC it is gonna be linked against. I.e. check whether the method is available, if so use it, else skip it. But forcing everyone to patch and compile/ship libFLAC when compiling/shipping Squeezelite, is a problem, at least for us.

from squeezelite.

I'll increment the version in my PR and use that to verify

Of course there is the risk that the version gets incremented for other reasons before the PR is merged. I am no C coder, but I guess there is a way to check whether the used function/symbol is available? That seems more failsafe to me.

from squeezelite.

I'll increment the version in my PR and use that to verify

Of course there is the risk that the version gets incremented for other reasons before the PR is merged. I am no C coder, but I guess there is a way to check whether the used function/symbol is available? That seems more failsafe to me.

Not really. I'll see if I can do something with weak functions but that would still to work with MSVC (sigh...)

from squeezelite.

Many thanks for the quick solution. I'll test this ASAP.

from squeezelite.

I was thinking about this too, because the newest GPIO code requires a newer version of libgpiod than is typically included with distributions, so I ended up statically linking the new version of just this library in my squeezelite build, so I could deploy it to all my players without having to manually build other packages on them. I was thinking that static linking the modified version of libFLAC might be the way forward here as well, so that it removes the tie to the distro's libFLAC version.

from squeezelite.

But it still means that you need to compile those patched or recent libraries at build time. Trying to use features/methods of libraries in a dynamic way, when they are available in the linked library, makes it easier for distributors. E.g. Debian themselves would decline statically linking libraries they ship with their own repo for dynamic linking.

However, requiring a newer version of a library is one thing, but requiring a patch to implement a feature which was never upstreamed is something entirely different, IMO 🙂.

I am happy to report that the change done with this PR works for us 👍: #208

from squeezelite.