3 ms·

Libraries don't exist in a vacuum with a single well defined user. If I'm shipping, say, libpng.so, and I need to do a one-time initialize per process, the only

Libraries don't exist in a vacuum with a single well defined user. If I'm shipping, say, libpng.so, and I need to do a one-time initialize per process, the only feasible way to do that is with a c++ static constructor or __attribute__((constructor)). It's why those things exist. It's why linker .ctors exist. It's why rust-ctor crate exists. It's why Java land re-created that by self-scanning all open jars for classes to randomly load. This is a very widely used capability and it is very definitely not trivial to just make an init function & define the import dag and have that work reliably. People will forget to call it & most of the time they won't have any clue what their dependency DAG even is. And that's assuming it can even form a DAG at all - cyclic dependencies are absolutely a thing, after all.

ori_b 4y ago
Libraries exist with a well defined compiler. The solution is at the compiler level, using information coming from the import graph that exists in languages with a module system. And I'm not sure how you can forget to import a library and still expect to use it, assuming your language has a module system. C and C++ can't solve this problem, of course, due to textual inclusion.
- jcelerier 4y ago
  > The solution is at the compiler level, using information coming from the import graph that exists in languages with a module system. no, it isn't because your library has to integrate with other languages when you make native stuff. I should be able to call dlopen from any native language without having to care in which language your library was implemented, just calling my OS's dlopen / LoadLibrary OS API function should be enough. If this doesn't work, then your solution is just not acceptable in many cases, so yes you have to work with its limits.
  - ori_b 4y ago
    Can you explain how a compiler topologically sorting the entries in .init_array makes a library unusable? What breaks?

ori_b 4y ago

Libraries exist with a well defined compiler. The solution is at the compiler level, using information coming from the import graph that exists in languages with a module system. And I'm not sure how you can forget to import a library and still expect to use it, assuming your language has a module system. C and C++ can't solve this problem, of course, due to textual inclusion.

jcelerier 4y ago
> The solution is at the compiler level, using information coming from the import graph that exists in languages with a module system. no, it isn't because your library has to integrate with other languages when you make native stuff. I should be able to call dlopen from any native language without having to care in which language your library was implemented, just calling my OS's dlopen / LoadLibrary OS API function should be enough. If this doesn't work, then your solution is just not acceptable in many cases, so yes you have to work with its limits.
- ori_b 4y ago
  Can you explain how a compiler topologically sorting the entries in .init_array makes a library unusable? What breaks?