Since a long time (even of the latest stable release 2.068.2) DMD by default links in libphobos statically as part of all executables produced by it. AFAICS C and C++ compilers by default don't link in libc or libstdc++, and I don't see why DMD (and LDC, perhaps GDC too) is different.
Apart from that this is a needlessly wasteful utilization of user disk space (though today hard/soft memory may be considered cheap), to the person newly testing the D waters, it makes it appear as if even a Hello World in D is much much more bloated than in C/C++/<insert the name of another compiled-but-by-default-dynamically-linked language here>...
Therefore please make it so that DMD (and thus hopefully LDC and GDC too) links to libphobos dynamically and not statically by default. If any rare need makes it so that somebody needs a statically linked executable, presumably that would not be too hard to achieve.
Note: I *don't* think this is a dup of bug 987 which was for D1...
Comment #1 by destructionator — 2015-10-17T14:37:41Z
I absolutely, strongly disagree. Dynamic linking Phobos is a bad idea - it will lead to serious breakage around every corner for every application.
Phobos changes with every release. All executables compiled before an update will now be liable to break.
Phobos is not commonly installed on user's computers. To distribute D programs compiled with these defaults, we'd also have to distribute the library. That'd be a 10x size increase and a big hassle... and moves the update breakage to the user's side.
Phobos is also not commonly in the system library location, so on Linux, this means running programs won't work without either changing that or setting the library path, another big annoying hassle. I'd virtually break the zip distribution (which is Linux distro agnostic and used by those of us who aren't on .rpm or .deb).
I guarantee you this will cause a bigger support burden than 400 KB in hello world and very little benefit.
C and C++ are very different - their libraries are commonly installed with operating systems and don't break binary compatibility every couple months. If you want me to ever get on board with dynamic linking phobos, work to get it included with all the OSes as an independent end-user component first.
Comment #2 by ibuclaw — 2015-10-17T15:46:56Z
(In reply to Adam D. Ruppe from comment #1)
> I absolutely, strongly disagree. Dynamic linking Phobos is a bad idea - it
> will lead to serious breakage around every corner for every application.
>
> Phobos changes with every release. All executables compiled before an update
> will now be liable to break.
>
> Phobos is not commonly installed on user's computers. To distribute D
> programs compiled with these defaults, we'd also have to distribute the
> library. That'd be a 10x size increase and a big hassle... and moves the
> update breakage to the user's side.
>
Agreed. This is not a bug on our side, more it is a decision given to the package maintainers for various OS's.
Comment #3 by samjnaa — 2015-10-18T03:27:55Z
(In reply to Adam D. Ruppe from comment #1)
> Phobos changes with every release. All executables compiled before an update
> will now be liable to break.
A valid point, obviously which I didn't think of. Am I then correct in assuming that Phobos doesn't guarantee ABI stability as in """Minor releases are backwards binary and source compatible.""" (https://wiki.qt.io/Qt-Version-Compatibility)?
Very well – this means the request should be postponed till such a date that DMD starts doing stable versioning...
(In reply to Iain Buclaw from comment #2)
> Agreed. This is not a bug on our side, more it is a decision given to the
> package maintainers for various OS's.
How is it a decision for package maintainers? In my experience, package maintainers don't like to fiddle with the default behaviour of software.
Comment #4 by Marco.Leise — 2015-10-21T21:36:02Z
(In reply to Adam D. Ruppe from comment #1)
> I absolutely, strongly disagree. Dynamic linking Phobos is a bad idea - it
> will lead to serious breakage around every corner for every application.
>
> Phobos changes with every release. All executables compiled before an update
> will now be liable to break.
You link to a versioned soname "ldd `which dub`":
libphobos2.so.0.68 => /opt/dmd-2.068/lib64/libphobos2.so.0.68
This way dub wont break when I install 2.069 and the package manager is smart enough to keep the library around until I recompile dub with the more recent version of Phobos.
> […]
>
> Phobos is also not commonly in the system library location, so on Linux,
> this means running programs won't work without either changing that or
> setting the library path, another big annoying hassle. I'd virtually break
> the zip distribution (which is Linux distro agnostic and used by those of us
> who aren't on .rpm or .deb).
>
> […]
>
> If you want me to ever get on board with dynamic linking phobos, work to get
> it included with all the OSes as an independent end-user component first.
The risk of ABI breakage between compiler versions makes it so that I still have to install GtkD (and other libraries) into separate compiler-arch-version specific directories. As for DMD's Phobos itself, two files don't carry the version in their name:
libphobos2.a
libphobos2.so
libphobos2.so.0.69
libphobos2.so.0.69.0
I'll look into moving the other two into system library path. It still doesn't solve anything when it comes to additional libraries. God knows what happens when you compile with dmd-2.069 and link to a library that was compiled against Phobos-2.068 or with a different D compiler.
Comment #5 by robert.schadek — 2024-12-13T18:45:23Z