Builds failing after upgrading to NDK 22.0.7026061

[tmm1]

Generating app/src/main/jniLibs/x86/jnijavacpp.cpp
Generating app/src/main/jniLibs/x86/jniHDHRLib.cpp
Compiling app/src/main/jniLibs/x86/libjniHDHRLib.so
/usr/local/share/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ -gcc-toolchain /usr/local/share/android-sdk/ndk-bundle/toolchains/x86-4.9/prebuilt/darwin-x86_64/ -I/usr/local/share/andr
oid-sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/include/ -I/usr/local/share/android-sdk/ndk-bundle/sources/cxx-stl/llvm-libc++abi/include/ -I/usr/local/share/android-sdk/ndk-bundle/sources/android/support/include/
 app/src/main/jniLibs/x86/jniHDHRLib.cpp app/src/main/jniLibs/x86/jnijavacpp.cpp -O3 -s -msse3 -ffast-math -mfpmath=sse -Wl,-rpath,lib/
-D__ANDROID_API__=21 -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -target i686-none-linux-android -march=i686 -mtune=atom -Wall -nostdlib++ -fPIC -shared -Wl,--no-undefined -z text -o li
bjniHDHRLib.so -Wl,-soname,libjniHDHRLib.so -L/usr/local/share/android-sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/libs/x86/ -Lapp/src/main/jniLibs/x86 -lhdhomerun -llog -lc
++_static -lc++abi -landroid_support -ldl -lm -lc
In file included from app/src/main/jniLibs/x86/jniHDHRLib.cpp:27:
/usr/local/share/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/../sysroot/usr/include/jni.h:30:9: error: unknown type name 'uint8_t'
typedef uint8_t  jboolean; /* unsigned 8 bits */
        ^

[tmm1]

There seems to be some change in how the sysroot headers are packaged:

$ ls -d /usr/local/share/android-sdk/ndk/21.3.6528147/sysroot
/usr/local/share/android-sdk/ndk/21.3.6528147/sysroot

$ ls -d /usr/local/share/android-sdk/ndk/22.0.7026061/sysroot
ls: cannot access '/usr/local/share/android-sdk/ndk/22.0.7026061/sysroot': No such file or directory

cc android/ndk#1407

[saudet]

The NDK now also comes with a proper cross compiler directory structure, so we might as well use that:
https://developer.android.com/ndk/guides/other_build_systems
That's pretty much considered an industry standard, so that should be forward compatible.

Updating the properties like this, for example, in the case for android-x86_64, seems to work for me:

platform.compiler=toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android21-clang++

What about you?

[tmm1]

I'm trying it now, but I'm still struggling with the issue in #341 (comment)

I don't use maven, I have a simple makefile that runs a command as follows:

java -jar javacpp.jar net/tmm1/package/HDHRLib \
-properties android-x86-clang \
-Dplatform.root=/usr/local/android-sdk/ndk-bundle \
-Dplatform.compiler=toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android21-clang++

As part of this invocation, I want to add my own linker and header paths. The only way I can see to do this is using -Dplatform.includepath=mybuildroot/include -Dplatform.linkpath=mybuildroot/include. However when I do that, it overrides all the default include/link paths which are required for android from the android-x86-clang.properties file. Is there a simpler way I can inject my own cflags/ldflags without having to keep my own copy of platform.linkpath in sync with the default properties?

[saudet]

Right, it's not really made to be used on the command line like that... We'd have to update the command line interface with options similar to includePath and such as with the plugin for Maven. For now though the easiest thing to do is to copy the properties file, modify it like you need it, and call java -jar javacpp.jar -propertyfile yourandroid.properties.

[saudet]

You could also probably use -Xcompiler and still be able to specify paths in a portable way too since the compiler is the same on all host platforms.

[tmm1]

Unfortunately that doesn't scale up for me, since I'm running this across 4 architectures and multiple libraries, each of which has a different set of include/link paths following a specific pattern.

If you can describe how you'd like to support this use-case, I am happy to open a PR with an implementation as this is becoming quite a hassle on my end.

That said, I did try what you suggested with a single lib/arch and it does work as expected using -Dplatform.compiler=toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android21-clang++

[saudet]

Unfortunately that doesn't scale up for me, since I'm running this across 4 architectures and multiple libraries, each of which has a different set of include/link paths following a specific pattern.

If you can describe how you'd like to support this use-case, I am happy to open a PR with an implementation as this is becoming quite a hassle on my end.

-Xcompiler should do what you need for paths on Android, but if you need more, have you taken a look at Gradle JavaCPP?

That said, I did try what you suggested with a single lib/arch and it does work as expected using -Dplatform.compiler=toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android21-clang++

Ok, great! Let's at least get that in. Please send a pull request :)

[tmm1]

That said, I did try what you suggested with a single lib/arch and it does work as expected using -Dplatform.compiler=toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android21-clang++

Looks like I mis-spoke. I didn't have NDK r22 on my dev machine. Once I upgraded, it's failing in the same way as I experienced before on my deployment infrastructure, with confusing stdint errors:

/Users/tmm1/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/../sysroot/usr/include/jni.h:30:9: error: unknown type name 'uint8_t'
typedef uint8_t  jboolean; /* unsigned 8 bits */

My guess earlier was this had to do with the fact that the sysroot directory is missing, but platform.includepath references sysroot/ twice in its include path.

If I look at the contents of that jni.h path mentioned in the error message, an #include <stdint.h> is one of the very first lines. So I assume its the rest of the include path that's causing a broken stdint.h to get included somehow?

[saudet]

Maybe it's the --sysroot= option that is incorrectly overriding the new default?

[tmm1]

I tried -Dplatform.sysroot.prefix= -Dplatform.sysroot= but no difference.

[tmm1]

Removing sources/cxx-stl/llvm-libc++/include/ from platform.includepath makes the compile succeed. But then its failing at linker stage:

ld: error: cannot open crtbegin_so.o: No such file or directory
ld: error: unable to find library -llog
ld: error: cannot open crtend_so.o: No such file or directory

So platform.linkpath is likely also incorrect now with the new layout.

[saudet]

We probably don't need any of those flags with the standalone version of Clang anymore.

[saudet]

I'm thinking we could move android-arm64.properties, etc to android-arm64-gcc.properties, etc as legacy properties, and have the main android-arm64.properties, etc be clean versions that resemble something saner like we have in linux-arm64.properties, etc. What do you think?

[tmm1]

Sounds good to me.

I'm making some progress figuring out what has to go inside these new properties files, but am getting stuck on this error:

ld: error: cannot open crtbegin_so.o: No such file or directory
ld: error: unable to find library -llog
ld: error: cannot open crtend_so.o: No such file or directory

I think it has to do with link order. Even though I'm using -Dplatform.link=c++abi#:c++_static#:log# the resulting command says -llog -lc++_static -lc++abi

If I put -llog at the end it works.

[tmm1]

Scratch that, the issue is with the inclusion of -target i686-none-linux-android

[tmm1]

Everything is working for me again with #444 and NDK r22

As an added bonus, linkpath and includepath are now empty by default so it's trivial for me to put my custom paths in there.