I'd vote for 3 (using shared lib).<div> </div><div>This is still an ALPHA, ABI breakages are to be expected, and if someone complains - he is missing the point. Better to have a good solution that works than a hacky workaround, IMO. On Wednesday, 22 August 2012 07:32:10 UTC+2, BogDan  wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello everyone,

<br>

<br>We've faced some big problems which prevent us to release alpha4 SDK,

so, I think we own you some explanations why we delay it that much.

<br>

<br>  First problem we've encountered it was the changes done in QtCreator

<br>(by Nokia guys), which delayed the release with more than 2-3 weeks,

<br>then we had to wait for ssl certificates for Ministro to arrive, then

<br>we've discovered that the official Android NDK had to be rebuilt for

<br>all platforms, then, again, we've found problems in QtCreator, then

<br>the SDK installer keep me busy for a couple of days, then we've face

<br>even more problems with Ministro [1] and now we've found the biggest

one, which might break some apps.

<br>The problem is the C++ support on Android. The default libstdc++

<br>library is useless, it contains only "new", "delete", "type_info"

<br>implementations, so we had to use something else which also comes with

stl support, so I choose to use the static gnu libstdc++.

<br>Shortly after we release alpha3 I found that is not very wise to use

<br>static libstdc++ on more than one library,

<br>android-ndk/docs/STANDALONE-<wbr>TOOLCHAIN.html says that:

<br>

<br>[quote]

<br>The standalone toolchain also comes with a copy of the GNU libstdc++

<br>library, which provides an implementation of the C++ Standard Template

<br>Library. To use it, you however need to link with the proper library:

<br>

<br>  * Use -lstdc++ to link against the _static_ library version. This ensures

<br>    that all required C++ STL code is included into your final binary. This

is ideal if you are only generating a single shared library or executable.

<br>

This is the recommended way to do it.

<br>

<br>  * Use -lgnustl_shared to link against the _shared_ library version. This

<br>    is required if you have several related shared libraries or executables

<br>    that need to run in the same address space at runtime (some global variables

<br>    need to be defined uniquely, which is not possible if you link the static

libstdc++ against each one of your executables).

<br>[/quote]

<br>

Now the question is, how to fix this problem without breaking the ABI?

<br>The answer it seemed to be easy, theoretically just adding the whole

<br>libstdc++ to QtCore should do the job [2], I loved myself for that

<br>idea, but ... not for a long time, because hey, in real life nothing

<br>is that simple, after we shipped the second testing SDK, Marco post an

<br>alarming message [3] on necessitas-devel mailing list. The problem

<br>seems to be easy to fix, because I removed the STL library from the

<br>mkspecs file, the STL test didn't  compile anymore and that it seemed

<br>it  was the reason for the problems, but again, "la vie en rose"

<br>doesn't apply to me, because soon I discover that the --whole-archive

<br>[2] flag is not working as it should, basically it doesn't export all

<br>the symbols from libstdc++ and you can not use only QtCore to link

<br>your STL apps. We (mostly Ray)  tried a lot of different paths but all

<br>of them ended badly, then Ray reported this issue to Google

<br><a href="http://code.google.com/p/android/issues/detail?id=36472" target="_blank">http://code.google.com/p/<wbr>android/issues/detail?id=36472</a><wbr>,  we really

hopped that we did something stupid but ... it seems we didn't.

<br>

<br>Now we must decide what we do next, we see the following solutions:

<br>1 - Release the SDK in a few days, but we must keep it as it is, try

<br>to embed the whole libstdc++ library into QtCore, even it is not

<br>exported all of it,but it seems it fixes the "static libstdc++"

problem described above, but we are not 100% sure.

<br>2 - Delay the release, and fix the bloody linker, make it export

<br>everything it should from libstdc++. The "static libstdc++" problem

will be 100% fixed (at least theoretically).

<br>3 - Delay the release, switch to shared libstdc++ library, but this

<br>move it will break the ABI, because all existing apps will search for

<br>stl and c++ symbols into QtCore not in the shared libstdc++. Of course

<br>we can not afford to break all existing apps, so we Ministro will need

more love to handle multiple ABI versions.

<br>4. Is a combination between first and the seconds solution: we ship

<br>the SDK now (1), but we (actually Ray is doing this tremendous job,

I'm just  the assistant)  keep working on (2).

<br>

Please let us know your opinions on this matter.

<br>

Any help with (2) will be very appreciated.

<br>

<br>Cheers,

BogDan.

<br>

<br>

<br>[1] <a href="http://www.omat.nl/2012/08/11/how-necessitas-grew-to-be-a-20tb-of-traffic-a-month-project/" target="_blank">http://www.omat.nl/2012/08/11/<wbr>how-necessitas-grew-to-be-a-<wbr>20tb-of-traffic-a-month-<wbr>project/</a>

<br>[2] <a href="http://quickgit.kde.org/index.php?p=android-qt.git&a=blobdiff&h=348a33a421017d7fd77426dec24736cadec83d1f&hp=d7306e05aca22ba519b7b4d3332197649619779f&hb=8c4c862ee26283d1f4cd698071d002577aff72df&f=src/corelib/corelib.pro" target="_blank">http://quickgit.kde.org/index.<wbr>php?p=android-qt.git&a=<wbr>blobdiff&h=<wbr>348a33a421017d7fd77426dec24736<wbr>cadec83d1f&hp=<wbr>d7306e05aca22ba519b7b4d3332197<wbr>649619779f&hb=<wbr>8c4c862ee26283d1f4cd698071d002<wbr>577aff72df&f=src/corelib/<wbr>corelib.pro</a>

<br>[3] <a href="http://mail.kde.org/pipermail/necessitas-devel/2012-August/001123.html" target="_blank">http://mail.kde.org/pipermail/<wbr>necessitas-devel/2012-August/<wbr>001123.html</a>

<br></blockquote></div>