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
__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
__dso_handle replacement/tracker example 1
__dso_handle replacement/tracker example 2
Often, it is defined in the stdlib:
- Subtle bugs caused by
__dso_handle being unreachable in some compilers
I ran into this problem. Here are the conditions which seem to reliably generate the trouble:
- g++ linking without the C/C++ standard library:
-nostdlib (typical small embedded scenario).
- 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.
- Note that I am not using a shared library of any type.
- 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:
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.
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.