~breakfastquay/rubberband#26: 
fatal error: 'jni.h' file not found

rubberband 3.1.1 fails to build for me on macOS 10.15.7:

../rubberband-3.1.1/src/jni/RubberBandStretcherJNI.cpp:28:10: fatal error: 'jni.h' file not found
#include <jni.h>
         ^~~~~~~
1 error generated.

Earlier meson said:

Java compiler for the host machine: javac (unknown 11.0.16.1)
Run-time dependency jni found: YES 11.0.16.1
meson.build:147: WARNING: Project targets '>= 0.53.0' but uses feature introduced in '0.62.0': dep 'jni' custom lookup.
  Build targets
    JNI library              : YES
                               Name: rubberband-jni

I have meson 0.63.3 installed.

If I edit meson.build to change 0.53.0 to 0.62.0 that removes the warning but does not fix the build.

I don't want anything related to Java, but I don't know what the meson equivalent of ./configure --help is so I don't know how to discover whether your build system offers a way to disable this feature.

Status
RESOLVED CLOSED
Submitter
~ryandesign
Assigned to
No-one
Submitted
2 months ago
Updated
a month ago
Labels
No labels applied.

~cannam 2 months ago

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.txt that deal with looking up jni.h, please? Should be a couple of dozen lines starting with the first reference to javac or jni.

~ryandesign 2 months ago

Sure, but all it says is:

Java compiler for the build machine: javac (unknown 11.0.16.1)
Java compiler for the host machine: javac (unknown 11.0.16.1)
Run-time dependency jni found: YES 11.0.16.1

Places where jni.h is located on my system that might be relevant:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jni.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jni.h
/Library/Java/JavaVirtualMachines/openjdk11/Contents/Home/include/jni.h
/opt/local/include/libavcodec/jni.h

~cannam 2 months ago

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.

~ryandesign 2 months ago

The failing command is:

/usr/bin/clang++ -Ilibrubberband-jni.dylib.p -I. -I../rubberband-3.1.1 -I../rubberband-3.1.1/rubberband -I../rubberband-3.1.1/src -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include/darwin -I/opt/local/include -fcolor-diagnostics -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++11 -O3 -pipe -Os -mmacosx-version-min=10.15 -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -DHAVE_VDSP -DHAVE_LIBSAMPLERATE -DLACK_SINCOS -DNO_THREAD_CHECKS -DNO_TIMING -DNDEBUG -DUSE_PTHREADS -DMALLOC_IS_ALIGNED -MD -MQ librubberband-jni.dylib.p/src_jni_RubberBandStretcherJNI.cpp.o -MF librubberband-jni.dylib.p/src_jni_RubberBandStretcherJNI.cpp.o.d -o librubberband-jni.dylib.p/src_jni_RubberBandStretcherJNI.cpp.o -c ../rubberband-3.1.1/src/jni/RubberBandStretcherJNI.cpp

So it has added -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include and -I/System/Library/Frameworks/JavaVM.framework/Versions/A/include/darwin but these directories don't exist. /System/Library/Frameworks/JavaVM.framework/Versions/A does exist, but it doesn't contain a directory with the headers. It's normal on macOS these days for headers not to exist in system paths. They exist in the macOS SDK instead. However, this is a framework, which means headers are in a Headers directory, not an include directory.

Even if the autodetection worked, it would be good to have an option to disable it. Package managers like MacPorts want to be very specific about what dependencies a package will use. If I've programmed the MacPorts rubberband Portfile not to depend on a Java installation, I don't want to discover that on some user's system that happens to have Java installed, it does end up installing Java-related files or, worse, fail to build. In an autoconf-based package, I would be looking for a configure flag like --disable-java to ensure Java is not used even if it's present.

~cannam 2 months ago

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=disabled

to 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=enabled

That 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!

~ryandesign 2 months ago

Thanks, this works for me.

I did still see this output, even though I'm using -Dauto_features=disabled and -Dfft=vdsp and -Dresampler=libsamplerate:

Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency fftw3 found: NO (tried pkgconfig, framework and cmake)
Run-time dependency sleef found: NO (tried pkgconfig, framework and cmake)
Run-time dependency sleefdft found: NO (tried pkgconfig, framework and cmake)
Run-time dependency samplerate found: YES 0.1.9
Run-time dependency speexdsp found: NO (tried pkgconfig, framework and cmake)
Run-time dependency sndfile found: YES 1.1.0

If rubberband will definitely use my specified fft and resampler even if it finds other ones then that's fine, it's just a little surprising to see it looking for programs/libraries that I've already told it I don't want.

I also noticed the program's version number is still 3.1.0.

~cannam 2 months ago

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.h and 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 for jni. Before that, jni was just looked up using pkg-config in 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 of auto_features=disabled is, 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.

~cannam REPORTED CLOSED a month ago

Register here or Log in to comment, or comment via email.