How about dynamic linking? Yeah, ok, that's hard. You might have to write an RTLD to link into the executable to find and load cosmo DLLs. Maybe not that hard... You could borrow BSD ld.so.1 code, I suppose.
Ah, that brings me to something else that someone like jart might want to take on:
# bringing static linking for C into the 21st century
What's wrong with static linking in C? Well, it's still stuck with 1970s semantics, while dynamic linking has much nicer semantics. Specifically:
- static linking flattens the dependency
tree, which causes
- symbol collision issues
- also, there's no RPATH equiv. for static
linking
My thinking is to:
- write dependency metadata (-lfoo, rpath,
-L/...) into a "hidden" .o that has just
this metadata encoded in it
- make the static linker look for that
metadata in dependencies and resolve
conflicts the same way as in dynamic
linking
- for each link-edit, including the final
link-edit of the executable, require
only that direct -lfoo dependencies be
listed
Linux has versioned symbols, and Solaris/Illumos has direct binding. The two schemes achieve roughly the same result: that the bindings made at link-edit time are the bindings you get a run-time.
In the versioned symbols case this is done via decorating symbols in the dependent with the SONAME and version of the dependency that is expected to provide them. In direct binding this is done by decorating symbols in the dependent with just the SONAME of the dependency that is expected to provide them.
The versioned symbol technique allows a shared object to provide multiple versions of a symbol with the same name, which can be useful for some things, but direct binding is just much easier to use than versioned symbols: just add `-B direct` to the link-edits and you're done.
Even in the absence of symbol versioning and direct binding, the fact that each object records its dependencies means that symbol conflicts will be only among those dependencies, and this can be discovered at link-edit time.
LD_PRELOAD interposers, on the other hand, can cause symbol conflicts in spite of all the foregoing. For this you can use `-B protected` or similar, but you may not want to.
Imagine you have a .cpp file with a global variable. Now imagine this cpp file is compiled into two different shared/dynamic libraries. And that both are loaded by some exe.
On Linux you’ll have one global variable. On Windows each DLL will have its own copy.
Which is better? It depends. Personally I think it’s much better for each shared/dynamic library to be a black box with a clearly defined API boundary. Thus I think the Windows approach is better.
The root evil here is that C++ is underdefined and what should really really really be a language level rule is actually left up to the platform.
I also think globals are evil and should almost never be used. But that’s a separate topic.
You missed the above commentary. If you use versioned symbols then the right thing will happen on Linux too: each shared object will have its own copy.
> The root evil here is that C++ is underdefined and what should really really really be a language level rule is actually left up to the platform.
Well, the issue is that C++ shares linking semantics with C, and C's linking semantics are not that well specified, because there's static linking -broken- and ELF -which has evolved to fix the problem you mention-.
Linux has eleventy billion config settings. If you very carefully set them, maintain them, and make regular blood moon sacrifices you can induce the desired behavior.
I think the Windows model is better. I think Linux generally handles shared libraries poorly.
You probably love Linux and think its preferences are great. That’s fine.
This is a matter of linker-editor defaults. Those defaults tend to be bad for backwards compatibility reasons. Yes, if you build software on Linux (or the BSDs, or Solaris, or Illumos distros) you have to know about this, or use frameworks that do.
The thing about defaults is that anyone can change them. It’s easy!
Also Google pays $26,000,000,000 a year to make sure Google is the default search engine. Because defaults are so easy to change that nobody changes them.
The Linux software community expects libraries to be written a certain way. It is a de facto platform configuration setting. Even if there are, per Linux tradition, a few flags.
Ah, that brings me to something else that someone like jart might want to take on:
# bringing static linking for C into the 21st century
What's wrong with static linking in C? Well, it's still stuck with 1970s semantics, while dynamic linking has much nicer semantics. Specifically:
My thinking is to: Well, anyways, it's a lot to ask :(