Modern C++ Lamentations

[Jonathan M Davis]

On Tuesday, January 1, 2019 5:40:21 PM MST Rubn via Digitalmars-d wrote:
> On Tuesday, 1 January 2019 at 22:34:24 UTC, Jonathan M Davis
>
> wrote:
> > The version number is in the file name for Phobos' shared
> > library, but if you're building the development version, that
> > really doesn't help you, because every time you rebuild it, you
> > get a file with the same name but potentially different
> > contents (at least until the next release gets tagged, and the
> > version number gets bumped). If you're only using releases, you
> > don't have that problem. However, unless you keep older
> > versions of the shared library around, as soon as you update,
> > all of your D programs break, because the version they need
> > isn't there anymore. All in all, it's just way simpler to use
> > Phobos as a static library. Sure, when you have a bunch of D
> > programs statically linked, it takes up a few extra megabytes
> > that way, but when systems have terabytes, that doesn't really
> > matter. Anyone who wants to use the shared library version is
> > free to do so, but I really don't think that it makes sense in
> > most cases. I do agree that shared library support in general
> > is something that we should have, but that doesn't mean that it
> > really makes sense as the default for the standard library -
> > especially when so much of it is templated anyway.
>
> Why wouldn't you keep older versions of phobos? Why are you
> deleting the old ones when you install a new version of DMD. They
> are designed in such a way to keep them there for this very
> reason. I don't really understand your argument here, to me it
> just seems DMD is just doing something backwards in comparison to
> the rest of the platform (as usual).

Anyone using a package manager to install dmd is only ever going to end up
with the version of Phobos that goes with that dmd. It would be highly
abnormal for multiple versions of Phobos to be installed on a system. The
only folks who would ever end up with multiple versions of Phobos on the
same system are folks actively going to the effort of making it happen
instead of using any of the normal install mechanisms. And ultimately, it's
far simpler to just always use Phobos as a static library rather than trying
to do anything with trying to keep older versions of the shared library
around - especially if you're actually building development versions of
Phobos.

In general, the only downsides to statically linking are that the
executables are slightly larger, and you don't get the benefit of security
updates to libraries without rebuilding the binary. And with how easy it is
to break ABI compatibility with D libraries (something as simple as a
function attribute changing breaks it, and that's trivial if the code is
inferring attributes), updating D shared libraries in a way that doesn't
require rebuilding the program is quite problematic in general. In some
situations, it's worth it, but in general, it really isn't. The place where
shared libraries offer far more benefit is with plugins and the like which
are loaded while the program is running rather than in trying to actually
share code. The ABI problems still exist there, but plugin APIs are
generally far more limited than full-on libraries (which reduces the
problem), and you simply can't use static libraries in those situations,
whereas if you're just linking your program against a library, static
libraries work just fine.

I'm by no means against having shared libraries in general work, and I think
that full dll support should exist for D on Windows, but aside from plugins,
in the vast majority of cases, I think that using shared libraries is far
more trouble than it's worth (especially with how difficult it is to
maintain ABI compatibility with D libraries).

> > The whole nonsense where you have to rebuild your program,
> > because _anything_ changed in the dll is just ridiculous IMHO.
>
> What?! Where did you hear this non-sense from? I'm not surprised
> at the state of shared library support on windows anymore.

>From working with dlls with C++. With dlls on Windows, your program links
against a static library associated with the dynamic library, and if any of
the symbols are changed, the addresses change, and your program will be
unable to load the newer version of the library without being rebuilt
against the new version of the static library. This is in stark contrast to
*nix where the linking works in such a way that as long as the symbols still
exist with the same ABI in the newly built library, they're found when the
program loads, and it's not a problem. The addresses aren't hard-coded in
the way that happens with dlls on Windows. dlls on Windows allow you to
share code so long as the programs are all built against exactly the same
version of the dll (and if they're not, then you need separate copies of the
dll, and you get into dll hell), whereas with *nix, you can keep updating
the shared library as much as you like without changing the executable as
long as the API and ABI of the existing symbols don't change.

- Jonathan M Davis