Victim of shared state, not shared libraries.

You can change floating point modes dynamically, and it's commonly done, and then it doesn't matter if the library was dynamically or statically linked.

But if you forget to change it back you may break other invariants, right?

Also, what about threads or fibers? I would guess it is thread-local but not fiber-local?

Depending on the implementation some green threads will save the mxcsr register during context switches (iirc ucontext does this on Linux) but some "fast" context switching libraries will intentionally avoid it to save some cycles since it requires a syscall.

If you're using fibers it's assumed you know what your doing.

That’s true about many cpu registers, but compilers take care of it correctly for everything except floating point flags.

That's just wrong.

The problem is a constructor in the .so being called as it's loaded. There is no way to guarantee state is safe between calls to functions loaded from shared libraries or when they're linked without expensive checks. The point is that there is state being mutated due to the fact we rely on shared libraries and allow dynamic libraries to mutate that state when they're loaded.

This is not a problem with statically linked libraries. And also note, I made a point of talking about shared libraries - not dynamic linking. They're not equivalent. The issue here is that the libraries are shared and do bad things, not that they're loaded dynamically. It would be fine if the library wasn't shared!

Statically linked libraries can have global constructors all the same, what are you talking about?