> the language has no concept of ownership of things like function pointers and pointers to static data. It's easy to imagine a better language

I actually have both a hard time imagining a better language (not saying it's impossible, just that it's not trivial for me to see) and also how ownership would resolve this issue. Could you elaborate?

I tested this recently and it definitely works as expected in c++ - destructors of static lifetime variables are called when the library is unloaded.

Only in trivial cases. The problem is when another part of the program holds a function pointer into the library which has been unloaded. This can happen in particular when you combine libraries and threads:

libvirt has long been linked with -Wl,-z -Wl,nodelete to avoid this:

https://gitlab.com/libvirt/libvirt/-/commit/8e44e5593eb9b89f...

Another case in libnbd which really demonstrates how hard this is:

https://gitlab.com/nbdkit/libnbd/-/commit/368e3d0d5a8871aad5...

> The problem is when another part of the program holds a function pointer into the library which has been unloaded.

How is this different from holding a pointer to an object being deleted?

That it's very hard to avoid (we think in fact impossible), because of the way that Linux _exit(2) works when you have threads, destructors and thread-local storage together. This is even if you are very careful. You should probably read the links I posted.

I did and this looks like a library design issue, which is now impossible to solve without breaking the ABI. I argue though that a design that doesn't suffer from this issue exists because there is a way to serialize all these operations in a safe way.

Thread-local storage + destructors is, as far as we can tell, impossible to use safely by any significantly complicated program or library. It's largely because of how Linux shoots down programs on exit by killing the threads in any order without notice. It could be fixed in Linux, although I can also understand why Linux developers wouldn't want to do that as it would push significant complexity there.

It's not much different. But programmers tend to assume that static data lives forever and don't always think of this problem.

Which is why that kind of stuff only works properly with languages that combine dynamic loading with rich runtimes, alongside automatic memory management, having all puzzle pieces to work together to keep the application running when the library is removed again.

I came to accept that in languages like C and C++, the best path for dynamic loading code is really via OS IPC and external processes, the decrease in hardware resources and simpler programming model of using shared libraries as plugins, isn't worth the endless amount of debugging hours regarding program crashes.