On Sunday, 11 August 2024 at 11:40:39 UTC, kinke wrote:
On Sunday, 11 August 2024 at 11:08:24 UTC, Denis Feklushkin
wrote:
Similar to how people can avoid explicitly linking GNU's
libstdc++ / LLVM's libc++ by using `c++` instead of `cc` as
linker driver, thereby not having to know which
implementation of the C++ std library to choose for the
particular platform.
Maybe in D case it will be right choice to respect
--defaultlib= setting during static linking? So if anyone
wants to link static library without stdlibs then just can
leave it empty. In other cases druntime and phobos will be
linked into static library?
This is NOT static **linking**, what you are asking for is
merging the D-default static libraries into a generated static
lib, to make it 'standalone' and thus simplify linking D parts
into another project.
Yes, I meant that.
But really I don't understand the fundamental difference with
static binary linking: there are "default libraries" and "just
libraries". But there is no fundamental difference.
Merging druntime and Phobos into a static lib is an extremely
exotic case, analogous to someone wanting to merge a static
libstdc++.a into their static C++ lib.
I don't see anything wrong with that. If everything around was
written in some other language, C++ people would have been forced
to add their runtime in a same roundabout way.
My opinion is that C/C++ are not a reference point here: they
created system as if there was only two languages, C and C++. The
very idea of "default libraries" is grist to the same mill.
So I don't see a good reason to support this use case by the
compiler directly.
It helps with cases discussed in this topic. Because world around
is written on C and C++, not on D. Build systems also isn't
supporting D in most - for example, I can't force cmake to search
the D standard library path to link target with it.
What you could e.g. do with a dedicated ldc2.conf is specifying
the paths to druntime and Phobos as regular default switches.
This will break a lot of things, it's easier to manually add a
similar hack into the build scripts
Ok, thanks to all! I think my question was completely cleared
