On Tuesday, 27 September 2016 at 10:46:23 UTC, Johan Engelen
wrote:
On Monday, 26 September 2016 at 23:32:05 UTC, Walter Bright
wrote:
Linking C libraries and object code into D programs has always
worked easily in D. The other way around, not so well.
[snip]
How much of an issue is this with D? Is it something we need
to address?
We've been toying with this in setting up LDC's build such that
it works on different platforms. […]
We've now moved to using the system linker separately to do the
linking.
To clarify: What we are doing in LDC is of course not what was
suggested in the initial post, i.e. linking D object files into C
executables without any (explicit) druntime dependencies and
expecting this to work.
The problem we were facing in particular is that many C/C++
libraries (such as LLVM) come with a list of linker flags to use
in the form of pkg-config or a similar tool. These will usually
be formatted for the default way of linking C on the system (i.e.
through a gcc-compatible interface). Thus, you can't just prefix
them with -L and forward them to the D compiler since that
forwards them directly to the low-level linker (-Xlinker, …).
This is a problem which *every* D project that wants to
seamlessly link against system C libraries on Linux needs to
solve.
There are two obvious ways to improve the situation:
- Like Johan suggested, add a D compiler flag that prints the
default linker flags used to create D executables.
- Add a D compiler flag to forward flags directly to the linker
driver used, without using -Xlinker.
Unfortunately, the LDC build system of course needs to work with
existing host compilers anyway, so these wouldn't have helped us
with shipping the first DDMD-based version. The most robust
solution I could come up with was to extract the linker command
line used from `$DMD -v some_test_executable.d` to then pass the
same flags directly to the system gcc when building the D program.
— David
