Comment by ~cannam on ~breakfastquay/rubberband
A simpler, heuristic-based solution would be to test for compiler and bitness, and pass -latomic whenever it is GCC on 32-bit platform
That's the sort of thing I want to avoid, because the heuristic would seem to have both false positives and false negatives
- The other issue linked was for a 64-bit system using Clang, not a 32-bit one using GCC, and it originally failed without
-latomic(albeit the reporter then found a fix at system level)- My own builds on 32-bit systems using GCC have not needed
-latomicI should have another scout around and see whether there's a Meson incantation to solve this - although I also don't really want to depend on a newer version of Meson!
Are you confident that this isn't an issue with the GCC/glibc combo? Should the runtime not be providing
libatomicitself if the atomics are not intrinsic?
Comment by ~cannam on ~breakfastquay/rubberband
See also https://github.com/breakfastquay/rubberband/issues/62 which remains without resolution.
Which platform and build chain are you using? My own 32-bit builds are currently working fine without
-latomic, and I have no idea how one would determine whether to add it explicitly or not.The Godot tracker linked from the Github issue also refers to failures caused by adding
-latomicon platforms that didn't need it, so I don't want to introduce it unilaterally.Perhaps there is a clear example of how to handle this somewhere? If so, nobody commenting on the other issue or the ones linked to it seems to have found it (and, needless to say, nor have I).
I would happily accept a patch if it works across all test platforms and comes with a convincing explanation of why it is correct.
Comment by ~cannam on ~breakfastquay/rubberband
REPORTED RESOLVED CLOSED
Comment by ~cannam on ~breakfastquay/rubberband
Thanks! I've made another change as well, since (even with the ability to switch off JNI manually) I was most unhappy with the autodetection failing in what looks like a pretty normal situation.
The new change is just that it doesn't take Meson's word for it when it reports having found the JNI dependency - it checks for Java, then checks for JNI using the built-in logic, then also checks that the compiler can find
jni.hand only goes ahead if that is true. So this should mean that a build without any feature overrides should do the right thing for you as well, now. I'd appreciate any feedback on this, since most of the changes in this area I've made so far have turned out to have unintended consequences!Couple of other notes:
WARNING: Project targets '>= 0.53.0' but uses feature introduced in '0.62.0': dep 'jni' custom lookup.- This is essentially because the meaning of the existing dependency lookup syntax changed in 0.62, so as to introduce a special case forjni. Before that,jniwas just looked up usingpkg-configin the normal way. Either of these is fine as far as it goes, since this is supposed to be an optional dependency anyway - so 0.62 is not actually needed despite the message, and since I still use CI environments with older versions of Meson, I don't want to require it."If rubberband will definitely use my specified fft and resampler even if it finds other ones" - it looks as if it hasn't found other ones... it has found only
libsamplerate, which is the one you wanted, and I can't tell for sure whether this is because the other libraries are not present or because it has short-circuited the checks to fail because the libraries were disabled on request. The message suggests the former but I wouldn't be certain! The build file is definitely written in such a way as to probe the libraries available before making a decision about which ones to use. The effect ofauto_features=disabledis, I believe, to act as if the probes fail rather than to alter the decision that is made. It is slightly too magical for my liking so I would certainly be curious about any situation in which it actually produces the wrong result.
Comment by ~cannam on ~breakfastquay/rubberband
Hm, yes that is quite poor isn't it.
I found the official Meson mechanism for enabling and disabling features, and have pushed a change to add support for it. You should be able to run
meson build -Djni=disabledto configure without JNI support. Also you can disable all optional features and then re-enable them individually, which sounds like what you might want if you're trying to be careful about dependencies. For example:
$ meson build -Dauto_features=disabled -Dcmdline=enabled -Dladspa=enabled -Dlv2=enabledThat might be a bit too laborious though, and it has the potential disadvantage that you might never even notice if a new optional target is added.
I'd be grateful if you can try this out and report how you get on!
Comment by ~cannam on ~breakfastquay/rubberband
If you run
ninja -v, it should print the commands run in the build, presumably ending with the one that fails. What is the full compiler command-line for that? I'd like to see whether Meson has decided to add some Java-related path to it, and if so, what that is.
Comment by ~cannam on ~breakfastquay/rubberband
Oh no, not again! It was an inconsistency in the Java/JNI lookup that prompted the 3.1.1 release in the first place - it was breaking builds for people who (like most of us) had no need of the JNI support. I really thought the fix in 3.1.1 should have solved it, and I was foolishly confident enough that I didn't add an explicit flag to disable it at the same time, as I should have.
I'm very curious about how and where Meson thinks it has found the JNI dependency, given that it then fails to find the header. Can you paste in the lines from
build/meson-logs/meson-log.txtthat deal with looking upjni.h, please? Should be a couple of dozen lines starting with the first reference tojavacorjni.
Comment by ~cannam on ~breakfastquay/rubberband
Thank you! It's in the 3.1.1 release now.
REPORTED RESOLVED CLOSED
Comment by ~cannam on ~breakfastquay/rubberband
Thanks for this, and for the added info at https://github.com/breakfastquay/rubberband/issues/73#issuecomment-1275612223 - I will give this a try and see how it fares in the CI environments.
Comment by ~cannam on ~breakfastquay/rubberband
Closing this one, as I can't currently think of any obvious improvement even though the current solution is still not totally ideal. It will do, I hope.
REPORTED RESOLVED CLOSED