CMake can't find SndFile (Ubuntu 24.04 / KDE neon) #1445
Comments
|
Starting with 2.4.0 fluidsynth relies on libsndfile's CMake configuration files in order to successfully discover libsndfile. Those are unfortunately not included in the Ubuntu package. So ideally this issue should be brought to https://launchpad.net/ubuntu/+source/libsndfile/+bugs asking to include the CMake config files like Edit: From my understanding one would only need to add to this file: https://git.launchpad.net/ubuntu/+source/libsndfile/tree/debian/libsndfile1-dev.install?h=applied/ubuntu/noble-proposed @LocutusOfBorg You seem to be one of the maintainers of Ubuntu's libsndfile package - may I ask you to take care of this? Alternatively, we could reintroduce our custom discovery magic through pkg-config, that I removed here: |
|
The problem is that SndFile has two build systems: the old traditional autotools-based build system, and a newer cmake based one. It shares a similar history with Fluidsynth, except that we removed the autotools once it was clear that cmake is better. The SndFile project did not perform this basic hygiene, and still has both. When building SndFile with auto-tools, the cmake support scripts are not used, generated or installed, and Fluidsynth is unable to find SndFile in these cases. Another layer of the problem is the lazy linux distros/maintainers, that prefer the old auto-tools better than learning the new cmake command. They will be unable to build the new Fluidsynth release, but anyway these lazy maintainers usually keep their deprecated packages for months or even years. This was anticipated here. Here are some links for people wanting to complain:
|
|
commit 4cdd9af :100644 100644 c12380d8 a696b473 M .azure/azure-pipelines-android.yml |
|
Theoretically, one should provide a new find package, and the old one as fallback, to help backporting of your fluidsynth to older releases. |
|
Sorry, I forgot about the fact that libsndfile still has two build systems. I do understand Pedros point that distro packages should be migrated and updated accordingly. But I also understand Locutus that such a change won't make it into any LTS branch. Locutus, would you prefer if someone files a ticket at launchpad, or Debian, or elsewhere? I think for the time being we should fall back to the previous pkg-config based discovery. Not doing so would definitely result in many bug reports like this one being filed here on Github, which doesn't really help anyone. |
I don't understand why not. When using the CMake based build system, the pkg-config .pc file is generated as well, and the package is discoverable and can be configured by other build systems. But when using the auto-tools build system, only the pkg-config .pc is generated, and other packages like Fluidsynth that expect .cmake configuration files are left in the cold. |
|
I tried to use cmake: Switching to cmake means no tests during build, this, for example, is a big regression compared with autotools. |
You may look into the msys2 approach: In short: they build it twice, static and shared. The unit tests are not run, but they install both versions (not only of libsndfile, but of every package). |
|
problem is after some quick debug:
their solution is:
my solution is:
Will share my progresses once I finish. (building twice is a sad approach in Debian packaging, not upstreamable and difficult to maintain. I'm not maintainer for the package, so my solution should be preferrably clean and short) |
|
This is something that works, but really needs cleanup and upstream apply |
So, to avoid building the package twice, your approach is to build the sources twice? If you add several targets with the same sources, every source will be compiled again for each target. To avoid this we use an object library in fluidsynth: Line 221 in 0f308a9 Which is used for building the library (shared or static): Lines 281 to 286 in 0f308a9 And it is also linked to the unit tests: |
|
Ok, so since there are apparently a few drawbacks in libsndfile's cmake based buildsystem, I have created a PR to restore our previous discovery magic. I have renamed our cmake find script to If I find some time over the holidays, I'll try to add the object library to libsndfile as pointed out by Pedro. |
I don't see a lot of drawbacks. The only thing is the incompatibility of unit tests with the shared library, and this would be only a problem if you need to run the unit tests, which should be done only when the maintainer apply patches before the upstream project does. Otherwise, the insistence of distros on running all unit tests in all circumstances is wasting CPU cycles, throwing up carbon dioxide, and a crime against the environment. But another argument against your revert: by doing that you may be holding back the project, just because others would like to hold back the world, instead of encouraging moving all of us ahead. The same that has held Linux irrelevant on desktops for decades.
It is your time to waste, but the libsndfile project has right now 143 open issues and 25 open pull requests (some are 4 years old). I guess that yours may be held there for months or even years (you already have opened an issue last month). Good luck, though. |
|
I disagree with you, Pedro. Being able to execute the unit tests is a legitimate reason - even for a package maintainer - as it ensures, that a particular build with a particular toolchain and configuration (compile flags, project internal build-flags, etc), works in such a way as it was intended by the developers. The intention behind #1454 is not to hold back the project, but rather to avoid breaking functionality that worked before. BTW, that's the same motivation why we're still using C90 and C++98, since we do have at least one WindowsXP user, and I'm not the one who wants to deliberate break stuff, just for the sake of moving forward. I do recognize that the libsndfile upstream dev has gone stale a bit. Yet, I do not consider it a waste of time, as is would bring the project forward. Pls. don't be so negative Pedro. From what I have perceived from Locutus, he is willing to port libsndfile to its CMake based buildsystem, when this issue has been sorted (provided, no other flaw is discovered). Not sure if I'll find the time though, because four more bugs have been filed recently... |
|
Hello @derselbst I'm willing to finish the work, I just had to fix like 10 other packages, but this one will come soon :) |
Compiling the latest 2.4.1 release on KDE neon (Ubuntu 24.04 base), CMake cannot find SndFile:
Version 1.2.2 of the
libsndfile1andlibsndfile1-devpackages are installed from the system repository, but CMake can't find them. All other dependencies are detected correctly. I cannot see any obvious CMake config files within the files installed bylibsndfile1-dev. Here is the list of files in that package:The text was updated successfully, but these errors were encountered: