Modern C++ Lamentations

[H. S. Teoh]

On Tue, Jan 01, 2019 at 07:04:24PM -0700, Jonathan M Davis via Digitalmars-d wrote:
[...]
> 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.

Wait, what?  Where did you get that idea from?  Since about a half
decade ago, Linux distros like Debian have had the possibility of
multiple versions of the same shared library installed at the same time.
It's pretty much impossible to manage a distro otherwise, since being
unable to do so would mean that you cannot upgrade a shared library
until ALL upstream code has been updated to use the new version.  Now
granted, most of the time new library versions are ABI compatible with
older versions, so you don't actually need to keep *every* version of
the library around just because some executable somewhere needs them.
And granted, splitting a library package into multiple simultaneous
versions is only done when necessary.

But the mechanisms for doing so have been in place since a long time
ago, and any decent distro management would include setting up the
proper mechanisms for multiple versions of Phobos to be installable
simultaneously.  Otherwise you have the untenable situation that Phobos
cannot be upgraded without breaking every D program currently installed
on the system.  Of course, for this to work, the soname needs to be set
properly and a sane versioning system (encoded in the soname) needs to
be in place. Basically, *every* ABI incompatibility (and I do mean
*every*, even those with no equivalent change in the source code) needs
to be reflected by a soname change. Which is likely not being done with
the current makefiles in git.  Which would explain your observations.
But it is certainly *possible*, and often *necessary*, to install
multiple versions of the same shared library simultaneously.


> 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.

I have no idea what you mean by "normal install mechanisms", because it
makes no sense to me to use any system-wide installation mechanism that
*doesn't* support multiple versions per shared library.  I mean, how do
you even get a sane operating environment at all?  It would be DLL hell
compounded with .so hell, episode II.

OTOH, if you're installing stuff by hand or by 3rd party installers
(which is generally a bad idea on Linux distros with a distro-specific
packaging system -- since colliding assumptions made by either side
means endless headaches on the user end), then you're on your own.
Maybe that's where you're coming from.


> 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.

Yes, for development builds, I'd tend to agree.


[...]
> 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.

Wow. That makes me glad I'm not programming on Windows...


> 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.
[...]

Yes, though the library authors / distributors will have to be extremely
careful to bump the soname for every ABI incompatibility.  All too often
people forget to do so, esp. when the ABI incompatibility is not
something directly caused by a source code change (the fallacious
assumption being "I didn't touch the source code, the ABI can't have
changed, right?"). And more often than people would like to admit,
sonames fail to get bumped even in the face of source code change, and
that's where things start getting ugly.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.