exception handling doesn't work when buding a share library which link gnu libstdc++ static lib

[wave]

recently, I want to port my own SDK from ubuntu to android.
the SDK are provided to application as a shared library, thus I build
a .so which links with gnu libstdc++.a.
because the SDK needs exception handling support.

in addition, I have another C++ program to test the SDK, so I build an
executable file also which links with gnu libstdc++.a and the
above .so file. after upload to /data and /system/lib, I try to run
the executable to test the SDK in the terminate, segmentation fault
occurs, it seems the exception handling in my code doesn't work.
steps: 1, g++, build sdk.so with libstdc++.a
2, g++, build test with sdk.so and libstdc++.a
3, run test, segmentation fault, exception handling doesn't
work.

I have to try again, build the SDK as a static lib, and link it to
executable file with libstdc++.a. the exception handling works.
I'm confused.
steps: 1, g++, build sdk.a
2, g++, build test with sdk.a and libstdc++.a
3, run test, exception handling works

I think that the difference between 2 times build is that the
executable file in the second build links to libstdc++.a only once
(default g++ will use link flag "-lstdc++ during building shared lib
and executable")
but I don't know why the exception handling doesn't work in this
situation, and when google will provide the libstdc++.so, it maybe
resolve my trouble.

I use NDK R6 android-9 on x86 platform. the language is c++.

anybody can help me. otherwise I have to rewrite a new test progream
using JAVA.

[David Turner]

That is normal (and works the same on standard Linux, iirc).

The issue is that the .so and the executable each have a distinct copy of C++ runtime functions/global variables.

Due to this, exception handling cannot work correctly when it crosses the shared-library / executable frontier.

If you statically link everything into a single shared library, or executable, the problem will not happen at all.

I intend to provide a shared library of libstdc++ in the next NDK release to avoid this. 

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Jie He]

thanks your help.

in addition, I tried to fool the ld, I build a SDK shared lib with the link flag "--whole-archive -lstdc++ --no-whole-archive". 

the shared lib should contain the whole libstdc++.

then I rename the .so to libstdc++.so, put it into the folder which is one of ld search folder.

re-build the executable, let it link with the new libstdc++.so.

from link trace, only this new libstdc++.so is linked, it seems I get a executable with one copy of libstdc++.a.

but test it on android, exception handling still doesn' work

steps: 1, build sdk.so with  "--whole-archive -lstdc++ --no-whole-archive"

          2, rename sdk.so to libstdc++.so

          3, build test only with the new libstdc++.so,

          4, check the dependencies, readelf -d test, which need sdk.so

          5, put test in /data, put sdk.so into /system/lib, run test, no link error, but exception handling still doesn't work

2011/8/31 David Turner <di...@android.com>

--
Best Regards
He Jie 何杰

[David Turner]

You can't call it libstdc++.so because there is already a system shared library by that name.

Call it something like libstdc++_shared.so instead and link against that. I'm not sure your approach is going to work though, but I'm curious to see if it does.

[Jie He]

yes, in the /system/lib, there is a libstdc++.so. but the exe didn't link it, because in its dependencies list, it dependents on the sdk.so, not libstdc++.so.

I just link the fake libstdc++.so during the linking process, because g++ is always going to link the libstdc++, I have to cheat it using the fake libstdc++.so.

and seems I succeed to cheat it, the exe only dependents on the sdk.so(which contains the whole libstdc++.a), but exception handling still doesn't work

[David Turner]

On Wed, Aug 31, 2011 at 11:05 AM, Jie He <jie....@gmail.com> wrote:

yes, in the /system/lib, there is a libstdc++.so. but the exe didn't link it, because in its dependencies list, it dependents on the sdk.so, not libstdc++.so.

I just link the fake libstdc++.so during the linking process, because g++ is always going to link the libstdc++, I have to cheat it using the fake libstdc++.so.

and seems I succeed to cheat it, the exe only dependents on the sdk.so(which contains the whole libstdc++.a), but exception handling still doesn't work

At this point, it probably depends on what your code does exactly. Do you have a simple test case to reproduce the issue? 

[Jie He]

yes, I wrote a simple case to test, using cmake, not ndk build.

another question, the exception handling can not catch the system-level exception (NULL pointer, div0 etc ) in NDK?
I wrote 2 cases, one throw std::runtime_error, can be caught; anther generate a NULL pointer or div0 exception, can not be caught. 

2011/8/31 David Turner <di...@android.com>

[wasabee18]

Hi all,

under the android-ndk-r6b\platforms\android-9\arch-arm\usr\lib folder,
there is indeed a libstdc++.so present.
why does'nt the standalone toolchain link against it ? especially when
explicitly passing the argument -lstdc++ as mentioned in the
STANDALONE-TOOLCHAIN.html document ?

David Truner said "I intend to provide a shared library of libstdc++

in the next NDK release to

avoid this".. but it is already present. Would this mean that this is
a compiler/linker issue rather than a missing lib ?

Cheers.

[David Turner]

On Tue, Oct 4, 2011 at 5:26 AM, wasabee18 <wasa...@gmail.com> wrote:

Hi all,

under the android-ndk-r6b\platforms\android-9\arch-arm\usr\lib folder,
there is indeed a libstdc++.so present.
why does'nt the standalone toolchain link against it ? especially when
explicitly passing the argument -lstdc++ as mentioned in the
STANDALONE-TOOLCHAIN.html document ?

The one under platforms/ corresponds to the system library (e.g. /system/lib/libstdc++.so)

This one does not support C++ exceptions, RTTI or any Standard C++ Library feature.

For these, you will need to use gnustl_static. stlport_static/shared can be used if you only need the Standard C++ Library, but no exceptions and RTTI.

The next NDK release will provide support for RTTI in stlport, though we hadn't the time to add exceptions support.

 

David Truner said "I intend to provide a shared library of libstdc++

in the next NDK release to

avoid this".. but it is already present. Would this mean that this is
a compiler/linker issue rather than a missing lib ?

It's not a shared library version of the GNU libstdc++, that's why :-)