We can build static library directly from the compiler:

$ ldc2 --lib app.d

produces app.a file with app.o inside of it.

Are there simple way to make a static library that also includes necessary standard D libraries (i.e., phobos2 and druntime)?

Compiler already knows (?) paths to default static libs because it have --static option which produces static executable with all necessary libs inside. (Although I'm not sure that it works by this way)

Point is that D can be not a main language of the project and it is unconvient to extract by somehow paths to phobos and druntime at last stages of project build.

On Friday, 9 August 2024 at 02:34:03 UTC, Denis Feklushkin wrote:

ldc2 has the --static option, though, looking from ldc2 --help I'm not 100% sure exactly what that does.

If that doesn't work we cat get a little creative:

$ cat hello.d
import std.stdio;

void main()
{
    writeln("hello, world!");
}
$ ldc2 -c hello.d # creates hello.o
$ gcc hello.o /usr/lib/x86_64-linux-gnu/libphobos2-ldc.a /usr/lib/x86_64-linux-gnu/libdruntime-ldc.a -lm -lz -o hello
$ ./hello
hello, world!
$

On Friday, 9 August 2024 at 22:32:21 UTC, Alex Bryan wrote:

$ cat hello.d
import std.stdio;

void main()
{
    writeln("hello, world!");
}
$ ldc2 -c hello.d # creates hello.o
$ gcc hello.o /usr/lib/x86_64-linux-gnu/libphobos2-ldc.a /usr/lib/x86_64-linux-gnu/libdruntime-ldc.a -lm -lz -o hello
$ ./hello
hello, world!
$

I had a similar issue, it almost made me drop D

https://forum.dlang.org/thread/yguvdwlqtyvmjrdsjkzo@forum.dlang.org

Whoever working on that kind of things needs to get this sorted ASAP

In other languages it is as easy as passing one argument

In D? it's yet again an obfuscated bloat

On Friday, 9 August 2024 at 22:32:21 UTC, Alex Bryan wrote:

--static means executable creation, not a static library

On Saturday, 10 August 2024 at 08:07:14 UTC, Denis Feklushkin wrote:

If i remember correctly, you have to pass --link-defaultlib-shared=false

On Friday, 9 August 2024 at 02:34:03 UTC, Denis Feklushkin wrote:

Nope, you'd have to specify the path to the libs explicitly in the cmdline to merge them into the created static lib/archive, e.g., ldc2 -lib bla.d $(dirname $(dirname $(which ldc2)))/lib/lib{druntime,phobos2}-ldc.a.

Not really; the -defaultlib libraries need to be in one of the lib-dirs in ldc2.conf, it's the linker that resolves them.

Would using the D compiler as linker driver be an option? 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.

On Sunday, 11 August 2024 at 08:30:05 UTC, ryuukk_ wrote:

No, I checked - it didn't work

On Sunday, 11 August 2024 at 10:18:56 UTC, kinke wrote:

Even if I use my custom ldc2.conf? I can specify necessary options in it

That's exactly what I meant in this case

For whole project code (it is ESP IDF) it is impossible, as for me, because C linker is nearly "hardcoded" into it. I use ldc2 as compiler for my D code and would to use ldc2 for linking this code with D standard libraries.

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?

On Sunday, 11 August 2024 at 11:08:24 UTC, Denis Feklushkin wrote:

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. 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. So I don't see a good reason to support this use case by the compiler directly.

What you could e.g. do with a dedicated ldc2.conf is specifying the paths to druntime and Phobos as regular default switches. Then they'll be merged into all static libraries that you create with that config file. Compilations are unaffected. [I guess linking would still work, but note that even with -defaultlib=, druntime and Phobos would be in every generated static lib and additionally in the linker cmdline.]

On Sunday, 11 August 2024 at 11:40:39 UTC, kinke wrote:

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.

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.

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.

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