Build fully static library by the compiler?

kinke noone at nowhere.com
Sun Aug 11 14:04:59 UTC 2024


On Sunday, 11 August 2024 at 13:16:16 UTC, Denis Feklushkin wrote:
>> 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

Yeah I'd probably prefer and go with that myself too. E.g., for 
the LDC CMake build, you can use the C++ compiler as linker 
driver (or the D host compiler); in that case, we need to pass 
the linker flags for host druntime+Phobos too, and do so by 
building a dummy-executable with the D host compiler and `-v`, 
and then parsing the printed linker cmdline.

Wrt. available options for linking D parts *statically* into a 
project in another language, I'd go in this order:
1. Use the D compiler as linker driver.
2. With a non-D compiler as linker driver, inject the required 
linker flags for the D parts, something like `-L<path to libs 
dir> -lphobos2-ldc -ldruntime-ldc`, in the correct position.
3. Otherwise merge all static D libs incl. druntime+Phobos to a 
single monolithic static lib (still depending on libc etc.) as an 
extra step.

Solution 3 could potentially be implemented in build systems like 
dub, which would then e.g. also allow you to create a 
'standalone' fat static lib for a dub project with regular 
static-lib dub dependencies, merging all of them, not just 
druntime and Phobos.

What I wrote earlier wasn't 100% exact:

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

They don't **need** to be in one of the lib-dirs, but can also be 
specified in the cmdline/config file via `-L-L<dir>`. So the 
compiler really doesn't know the exact location the linker would 
use (potentially even skipping dirs with libs for another target 
architecture etc.).


More information about the Digitalmars-d-learn mailing list