__dso_handle Symbol Bugfix in android-ndk-r6b

[Ken R]

Hi,

I was wondering if an NDK developer/maintainer could explain what
exactly was done in r6b to fix the toolchain linker warnings for the
"__dso_handle" symbol. From changelog:

* Fixed the standalone toolchain linker warnings about missing
the definition and size for the __dso_handle symbol (ARM only).

I am currently working on compiling native c++ code using stl
(specifically iostream) on my actual android device, and I have been
getting this warning using g++ 4.6.0.

I am a bit confused since symbol dump from libstdc++ in r6b still
reveals the following:

arm-eabi-readelf -s android-ndk-r6b/sources/cxx-stl/gnu-libstdc+
+/libs/armeabi-v7a/libstdc++.a | grep __dso_handle

330: 00000000 0 NOTYPE GLOBAL DEFAULT UND __dso_handle
165: 00000000 0 NOTYPE GLOBAL DEFAULT UND __dso_handle
56: 00000000 0 NOTYPE GLOBAL DEFAULT UND __dso_handle

Why is the type still "NOTYPE" instead of "OBJECT"? What was done to
eliminate the linker warnings?

Thanks

[Belvedere Computer Services]

i worked on this last night but could not find my way back here ~
dozens of posts on ( some compiler scripts i do not know about ) with
the threads ending off on "someone needs to do something about this"
and it just went off the radar on that

[Belvedere Computer Services]

oops found it on 2-nd try

{ no warranty and no want no warranty }

add

extern "C"
{
void *__dso_handle = NULL;
}

to main lib

linker quiets down

courtesy ta0kira
Senior Member
linuxquestions.org

On Oct 28, 1:06 am, Ken R <kj.rie...@gmail.com> wrote:

[Ken R]

Thanks. I was aware of the "extern C" workaround below. I was just
trying to find out what changes were made from r6 to r6b so that I
didn't have to manually define this symbol in every piece of code
compiled on my device. In case anyone is interested, the prebuilt
native ARM gcc toolchain that I am using can be found here:

http://rwiki.sciviews.org/doku.php?id=getting-started:installation:android

I've already used this to successfully compile several projects on my
actual device (my main reason for doing this is convenience when I am
away from my development machine). Everything goes smoothly except
for the linker warning.

From what was mentioned about compiler scripts, it sounds like
something was changed in the compilation of the (cross) compiler/
linker itself. If that is the case, I guess I'll stick with the
workaround.

On Nov 2, 12:38 am, Belvedere Computer Services <fa829...@gmail.com>
wrote:

> oops found it on 2-nd try
>
> { no warranty and no want no warranty }
>
> add
>
> extern "C"
> {

> void *__dso_handle= NULL;

[David Turner]

On Fri, Oct 28, 2011 at 8:06 AM, Ken R <kj.r...@gmail.com> wrote:

Hi,

I was wondering if an NDK developer/maintainer could explain what
exactly was done in r6b to fix the toolchain linker warnings for the
"__dso_handle" symbol.  From changelog:

    * Fixed the standalone toolchain linker warnings about missing
the definition and size for the __dso_handle symbol (ARM only).

I am currently working on compiling native c++ code using stl
(specifically iostream) on my actual android device, and I have been
getting this warning using g++ 4.6.0.

The issue is a bit complex. In a nutshell, __dso_handle must be defined for every shared library. It is used to handle static C++ destructors when the library is unloaded through dlclose(), or when the program exits.

The change was to move the definition of __dso_handle from the C library to the runtime object crtbegin_dynamic.o and crtbegin_static.o

You probably need to rebuild your toolchain using the versions that come with NDK r6b. Your toolchain install directory should contain a copy of the old ones. Maybe over-writing them with the newest objects should be enough, but I can't guarantee that a full rebuild isn't necessary.

 

I am a bit confused since symbol dump from libstdc++ in r6b still
reveals the following:

     arm-eabi-readelf -s android-ndk-r6b/sources/cxx-stl/gnu-libstdc+
+/libs/armeabi-v7a/libstdc++.a | grep __dso_handle

         330: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __dso_handle
        165: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __dso_handle
        56: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __dso_handle

Why is the type still "NOTYPE" instead of "OBJECT"?  What was done to
eliminate the linker warnings?

Thanks

--
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.

[Ken R]

On Nov 3, 10:56 am, David Turner <di...@android.com> wrote:
> The change was to move the definition of __dso_handle from the C library to
> the runtime object crtbegin_dynamic.o and crtbegin_static.o
>
> You probably need to rebuild your toolchain using the versions that come
> with NDK r6b. Your toolchain install directory should contain a copy of the
> old ones. Maybe over-writing them with the newest objects should be enough,
> but I can't guarantee that a full rebuild isn't necessary.

Thanks very much for the explanation/suggestion. Overwriting the C
runtime objects used by the toolchain on my device with the ones from
the latest NDK does eliminate the linker warning. The resulting
executables also appear to run normally.

Creating shared libraries via "g++ -shared ..." still produces the
warning. Perhaps "g++ -shared" links with a different runtime object?
Still, I don't think this is a big deal since __dso_handle is now
defined when an executable is linked with the shared object.

Thanks again.

[David Turner]

g++ shared should link with crtbegin_so.o / crtend_so.o, maybe you didn't copy these files?