Where is __dso_handle defined?

Question

I have an unresolved symbol error when trying to compile my program which complains that it cannot find __dso_handle. Which library is this function usually defined in?

Does the following result from nm on libstdc++.so.6 mean it contains that?

I tried to link against it but the error still occurs.

nm libstdc++.so.6 | grep dso
00000000002fc480 d __dso_handle

Answer 1

__dso_handle is a "guard" that is used to identify dynamic shared objects during global destruction.

Realistically, you should stop reading here. If you're trying to defeat object identification by messing with __dso_handle, something is likely very wrong.

However, since you asked where it is defined: the answer is complex. To surface the location of its definition (for GCC), use iostream in a C++ file, and, after that, do extern int __dso_handle;. That should surface the location of the declaration due to a type conflict (see this forum thread for a source).

Sometimes, it is defined manually.

Sometimes, it is defined/supplied by the "runtime" installed by the compiler (in practice, the CRT is usually just a bunch of binary header/entry-point-management code, and some exit guards/handlers). In GCC (not sure if other compilers support this; if so, it'll be in their sources):

• Main definition
• Testing __dso_handle replacement/tracker example 1
• Testing __dso_handle replacement/tracker example 2

Often, it is defined in the stdlib:

• Android
• BSD

Further reading:

• Subtle bugs caused by __dso_handle being unreachable in some compilers

Answer 2

I ran into this problem. Here are the conditions which seem to reliably generate the trouble:

1. g++ linking without the C/C++ standard library: -nostdlib (typical small embedded scenario).
2. Defining a statically allocated standard library object; specific to my case is std::vector. Previously this was std::array statically allocated without any problems. Apparently not all std:: statically allocated objects will cause the problem.
3. Note that I am not using a shared library of any type.
4. GCC/ARM cross compiler is in use.

If this is your use case then merely add the command line option to your compile/link command line: -fno-use-cxa-atexit

Here is a very good link to the __dso_handle usage as 'handle to dynamic shared object'.

There appears to be a typo in the page, but I have no idea who to contact to confirm:

After you have called the objects' constructor destructors GCC automatically calls the function ...

I think this should read "Once all destructors have been called GCC calls the function" ...

One way to confirm this would be to implement the __cxa_atexit function as mentioned and then single step the program and see where it gets called. I'll try that one of these days, but not right now.

Answer 3

Adding to @natersoz's answer-

For me, using -Wabi-tag -D_GLIBCXX_USE_CXX11_ABI=0 alongside -fno-use-cxa-atexit helped compile an old lib. A telltale is if the C++ functions in the error message have std::__cxx11 in them, due to an ABI change.