c++_shared question

[Steven Winston]

I was updating a project to the latest NDK.  Noticed that '-DANDROID_STL=c++_shared' in the cmake gradle closure causes this:

CMake Error: File /home/swinston/Android/Sdk/ndk/28.0.12433566/sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_shared.so does not exist.

Looking in said folder, it looks like cxx-stl is no longer in the sources directory.  Looking back in time I see that 23.1.7779620 is the last time I can find where that path that gradle provides is correct.  Given that there's several releases between then and now and assuming I'm not the only one using the SSL prefab; I'm assuming that the -DANDROID_STL=c++_shared is no longer the way to get the non C++_static library.  However, I only see documentation and sample code showing the same method I'm using.  Could someone point me in the right direction for where to find the correct updated docs?

Thanks!

[Dan Albert]

What version of AGP are you using? It looks like you're using something ~5 years old or older, which is too old to support modern NDKs.

assuming I'm not the only one using the SSL prefab

The "beta" label on that artifact should scare you. That is not maintained. It is out of date, and that's an especially bad thing for a library like OpenSSL.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/9b1d806a-a5f5-4fb7-88af-f0274babbd9fn%40googlegroups.com.

[Steven Winston]

AGP is 8.7.2 isn't that the latest?

For the OpenSSL I'm using it in an experiment project.  Technically the only time I really use OpenSSL on Android is when I go up to the Java layer and just use the system SSL.

[Dan Albert]

AGP is 8.7.2 isn't that the latest?

Even if it isn't, it's definitely new enough. For my first guess to have been correct you'd have had to be on 4.0 or something similarly ancient.

Something very weird is going on and I doubt anyone's going to be able to offer much useful advice without a repro case. The error message you quoted I think can only happen when either an old AGP version is being used, or an old NDK version is being used (or at least AGP thinks an old NDK version is being used). What you've described is the way you're supposed to do this. Like you said, the samples do it that way, and the samples aren't broken, so there's something weird going on. I assume you've already tried a clean build? (delete the .cxx directory, not just the build directory, in Studio that's the "Refresh linked C++ projects" button)

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/fbf6be92-6643-41ce-b9e7-b3992a621c35n%40googlegroups.com.

[Steven Winston]

Well I get to have egg on my face for not investigating it fully.  Intel's TBB is to blame.  Looks like it got included from a externalProject_add inside of a dependency that mediapipe is using.  Which is why this is in my test / validation project.  Looks like the cmake in TBB is using has this nugget:

if (ANDROID_PLATFORM)
    if ("${ANDROID_STL}" STREQUAL "c++_shared")
        configure_file(
        "${ANDROID_NDK}/sources/cxx-stl/llvm-libc++/libs/${ANDROID_ABI}/libc++_shared.so"
        "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libc++_shared.so"
        COPYONLY)
    endif()
    # This custom target may be implemented without separate CMake script, but it requires
    # ADB(Android Debug Bridge) executable file availability, so to incapsulate this requirement
    # only for corresponding custom target, it was implemented by this way.
    add_custom_target(device_environment_cleanup COMMAND ${CMAKE_COMMAND}
                      -P ${CMAKE_CURRENT_SOURCE_DIR}/cmake/android/device_environment_cleanup.cmake)
endif()

Cool, thanks Dan!  Oh and good to see you're still kicking around.  I'll try to not disturb you guys unless I really run a bug down first in the future.

[Dan Albert]

Yep, that'll do it. I guess they were trying to build their own packaging system but aren't compatible with modern NDKs?

And no worries. "Oops, the bug became obvious once I tried to reduce a test case" is a pretty common experience for me too :)

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/ce2927f8-46e0-4da7-a29b-f5701872fbedn%40googlegroups.com.

[Steven Winston]

I didn't debug too much further for the TBB.  Left fixing it as an exercise for the future reader that happens upon this.

I didn't know if this was a bug or missed docs or they moved or something.  I just figured I was ignorant of a new change which is why this wasn't in a bug report.

My goal was to get mediapipe building from source using bazel from AS the same way I have it in CLion.  So, all I had to do was rearrange the order in which cmake is defining the targets that come out of bazel such that only bazel has to deal with the nonsense of whatever package the bazel project dependencies decided to do and leaves cmake out of those dependencies.  It looks like it worked; although maybe somewhere down the pipe one of those packages is specifying the version of the NDK??  That or maybe whatever part of the mediapipe library that is including it doesn't use CMake and has a fix in the Bazel build file which seems likely now that I think about it.