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