4 ms·

Okay but we're talking about native languages where you are bound by the rules of your platform's dlopen / LoadLibrary implementation ; this is where so many st

Okay but we're talking about native languages where you are bound by the rules of your platform's dlopen / LoadLibrary implementation ; this is where so many static initialisation bugs lurk, when you load libraries dynamically

ori_b 4y ago
No, you're not. The fact that a misfeature exists in the toolchain doesn't force you to use it. You can order the init sections on your own when you generate the binaries and add your own constraints, and if your toolchain doesn't give you that control, you can generate and call your own init functions. (Since I didn't want to dick with the linker too much, I generated my own init functions in my natively compiled language to solve this problem). Your language's dlopen wrapper can also dlsym the initializer and call it if it's present. This is very much a C++ problem, because its separate compilation model throws away initializer ordering, and prevents the compiler from doing anything about it. And, of course, compatibility makes this a tough sell for C++ -- languages unconstrained by history don't have to worry about this. tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main.
- kllrnohj 4y ago
  > tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main. How does my shared library do that?
  - ori_b 4y ago
    def loadlib() { lib = dlopen("libfoo.so") sym = dlsym(lib, "pkgname.__init__") sym() return lib } Hell, you can even do this with a single constructor attribute that runs the initializer, if you want to be fully dlsym compatible. If you have a DAG of dependencies, it's impossible for your library to care whether main or dlopen has called its initializer, because the same initialization order of dependencies is observed in either case. The only thing you need to beware of is guarding against double-init if you dlopen, and the generated library-level initializer code can do that.
    - kllrnohj 4y ago
      So the answer is you can't, and you're just too stubborn to say as much. Not all languages need all features, zig is allowed to just be insufficient for things, this being one of them.
      - ori_b 4y ago
        ??? If you generate a single initialization symbol that guards against multiple runs in the init section, this works just fine with dlopen. This isn't even hard, but you need to be able to form a full dag of imports. The only problem is that the linker slams together the .init, .ctors, or .init_array sections in some arbitrary order (usually the order that .o files are passed in on the command line, but there are no guarantees). If you topologically sorted the object and library list by import order, things would work out. But because the linker doesn't cooperate, a language that wants to avoid the initialization order fiasco needs to provide its own ordering. Or its own linker. As far as Zig goes -- I have no clue what it does. Never touched it. Also, as a side note -- initializers were initially designed so that there would be exactly one init function per binary or library, and then people wanted to split the initialization up, so the way the init section ends up getting constructed on most unixes is fascinatingly hacky: The linker links `crti.o`, your .o files, `crtn.o`. crti.o contains a function prologue; the init sections in your .o files contain a sequence of call functions, and crtn.o contains a function epilogue. Stitch them all together in order, and you get a single function that you can call. This is deprecated, and now there's a table of function pointers (.init_array).
        kllrnohj 4y ago
        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

No, you're not. The fact that a misfeature exists in the toolchain doesn't force you to use it. You can order the init sections on your own when you generate the binaries and add your own constraints, and if your toolchain doesn't give you that control, you can generate and call your own init functions. (Since I didn't want to dick with the linker too much, I generated my own init functions in my natively compiled language to solve this problem). Your language's dlopen wrapper can also dlsym the initializer and call it if it's present. This is very much a C++ problem, because its separate compilation model throws away initializer ordering, and prevents the compiler from doing anything about it. And, of course, compatibility makes this a tough sell for C++ -- languages unconstrained by history don't have to worry about this. tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main.

kllrnohj 4y ago
> tl;dr: Ignore the constructor attribute/init section, and generate your own function that orders things correctly. Then call it before main. How does my shared library do that?
- ori_b 4y ago
  def loadlib() { lib = dlopen("libfoo.so") sym = dlsym(lib, "pkgname.__init__") sym() return lib } Hell, you can even do this with a single constructor attribute that runs the initializer, if you want to be fully dlsym compatible. If you have a DAG of dependencies, it's impossible for your library to care whether main or dlopen has called its initializer, because the same initialization order of dependencies is observed in either case. The only thing you need to beware of is guarding against double-init if you dlopen, and the generated library-level initializer code can do that.
  - kllrnohj 4y ago
    So the answer is you can't, and you're just too stubborn to say as much. Not all languages need all features, zig is allowed to just be insufficient for things, this being one of them.
    - ori_b 4y ago
      ??? If you generate a single initialization symbol that guards against multiple runs in the init section, this works just fine with dlopen. This isn't even hard, but you need to be able to form a full dag of imports. The only problem is that the linker slams together the .init, .ctors, or .init_array sections in some arbitrary order (usually the order that .o files are passed in on the command line, but there are no guarantees). If you topologically sorted the object and library list by import order, things would work out. But because the linker doesn't cooperate, a language that wants to avoid the initialization order fiasco needs to provide its own ordering. Or its own linker. As far as Zig goes -- I have no clue what it does. Never touched it. Also, as a side note -- initializers were initially designed so that there would be exactly one init function per binary or library, and then people wanted to split the initialization up, so the way the init section ends up getting constructed on most unixes is fascinatingly hacky: The linker links `crti.o`, your .o files, `crtn.o`. crti.o contains a function prologue; the init sections in your .o files contain a sequence of call functions, and crtn.o contains a function epilogue. Stitch them all together in order, and you get a single function that you can call. This is deprecated, and now there's a table of function pointers (.init_array).
      - kllrnohj 4y ago
        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.