Why not use GCC constructor/destructor?

Question

libabc recommends not using GCC constructors/desctructors, but the explanation is rather short:

Do not use gcc constructors, or destructors, you can only loose if you do. Do not use _fini() or _ini(), don't even use your own explicit library initializer/destructor functions. It just won't work if your library is pulled in indirectly from another library or even a shared module (i.e. dlopen())

Can someone explain what the problems are and what could break, especially with GCC on different platforms?

Answer 1

When writing a library, the best approach is to have no dependencies on other libraries, no dependencies on state data at all (certainly no use of global variables for state and synchronization within the library), clean and simple interfaces, and all of the other basic principles of good software engineering.

What the README for libabc is providing is a fairly good list of all the ways that the writers have found to make a library difficult to use or to introduce various kinds of subtle defects.

What the authors are saying is that it is difficult to predict how your library will be used and the environment in which it will be running therefore you should be paranoid about how you implement functionality and what kinds of services from the operating system and any other libraries you might use.

For instance see Shared Library Constructor is not executed.

Or When (and how) are C++ global static constructors called.

Or GCC constructor NOT execute.