Why not use the GCC constructor / destructor?

Question

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

Do not use gcc constructors or destructors, you may lose if you do. Do not use _fini () or _ini (), do not even use your own explicit library initializer / destructor functions. It just won’t work if your library touched indirectly from another library or even a common module (i.e. dlopen ())

Can someone explain what problems and what might break, especially with GCC on different platforms?

Answer 1

When writing a library, the best approach is the absence of dependencies on other libraries, the absence of dependencies on state data in general (of course, not using global variables for state and synchronization in the library), clean and simple interfaces and all the other basic principles of good software development.

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

What the authors say is that it is difficult to predict how your library will be used and the environment in which it will work, so you have to be paranoid about how you implement the functionality and what types of services from the operating system and any other libraries you can use.

For example, see Public Library Designer fails .

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

Or the GCC constructor is NOT executed .