figure out bog-dan-ro's gnustl woes

[DanAlbert]

#67 (comment)

@bog-dan-ro: I wanted to get a better understanding of your comments in the other bug, but didn't want to drag that one off topic with STL things.

But we still need to keep using gnu stl (for binary compatibility)

Could you explain what ABI compatibility you're aiming for with gnustl here? There aren't any guarantees of ABI compatibility across NDK releases. The advice we've given to other apps/libs that want to maintain STL ABI compatibility across NDK releases is that they need to actually ship an STL as part of their apps (ship headers and libraries that dependents use rather than those in their NDK). It's the only way to guarantee that it will work.

therefore pretty please with sugar on top do not remove it :) !

Removing it is definitely planned, but I think we can do this in a way that will still allow people to keep using it. A very common complaint we receive from all sides is that the sheer number of STLs we support is confusing, and supporting more than one means that it's very difficult to depend on third-party NDK libraries in your app because they have to all use the same STL or it won't work.

ndk-build has actually gotten smart enough lately that I don't think we actually need to treat STLs special in comparison to other libraries now. I believe that when we remove gnustl from the NDK we should be able to put the libs up in a separate project and anyone that wants to continue using them should just be able to clone the repository and pull it in with $(call import-module) with APP_STL := none (or continue using it however their custom build system already does).

[bog-dan-ro]

Sure, currently there are two way to use Qt libs on Android:

• bundling all of them in the same .apk with the application itself, using the technique it will not be a problem using a different libc++.
• using Ministro service to download Qt libs. The user .apk has only the application .so files, when it starts it connects to Ministro service and it sends a list with all the libs it needs to run. Ministro download (the missing) libs into his own home folder, chmod 644 all of them (this way they are read-only for all apps) and send back the application the libs list that it has to load before it loads the application .so file. Once every week Ministro check if there are updates of the downloaded libs and it downloads them. This way all the apps uses the latest libs with security fixes. If I stop using gnu libstdc++ and switch to llvm's one, I'll break all the existing apps, which is a no go for me :).

[DanAlbert]

Yeah, that poses some issues. It sounds like the solution I suggested would work here though (and Ministro would be able to enforce that the same gnustl was used for all apps). Sound right to you?

[bog-dan-ro]

GNU STL has a long history of compatible API/ABI, we had no problems with any NDKs ...
Shipping gnustl as part of the user's apk is not possible with Ministro, because Qt libs might depend on a newer version. Also loading two gnu libc++ is also not ok :).

As long as you keep it where it is now and don't do any changes that will break the API/ABI, there will be no problem for us, because Qt's build systems (qmake, cmake, qbs) will know how to pick the right one.

IMHO the best way to solve this problem is you to add it to Android system libs :D.
Now that you already "polluted" Android with GPL, there is no reason for you not to ship GNU's libstdc++ ;-).

[DanAlbert]

GNU STL has a long history of compatible API/ABI, we had no problems with any NDKs ...
Shipping gnustl as part of the user's apk is not possible with Ministro, because Qt libs might depend on a newer version. Also loading two gnu libc++ is also not ok :).

What I'm suggesting is that you make gnustl part of the Qt SDK. Can either distribute libgnustl_shared.so through ministro or just have users build agains the same libgnustl_static.a that you have for the static Qt libs.

As long as you keep it where it is now and don't do any changes that will break the API/ABI, there will be no problem for us, because Qt's build systems (qmake, cmake, qbs) will know how to pick the right one.

gnustl will be removed from the NDK, for the reasons I outlined in the original post. As I said though, I believe we can do this in such a way that it can be cloned (can sort of think of it as an optional NDK component, I suppose).

[bog-dan-ro]

I'll think about to a solution ... but I'm pretty sure that Qt is not the only project that will be unhappy with your decision to remove GNU's STL from NDK ...

[DanAlbert]

We have an understanding of the situation now.