On Tuesday, 8 September 2026 at 21:07:20 UTC, Rambutan wrote:
I started a discussion here, following your suggestion. I'm
beginning to understand what the issues are.
https://github.com/dlang/dmd/discussions/23814
After some thought I have formed the following working hypotheses
about successful linkage of D interface files.
1. A D interface file connected to a D application or project.
The result of compiling a .di file is minimal so as not to
duplicate parts of the D application they correspond to.
Nevertheless some necessary implicit type-related symbols may
well be created by this compilation, so in general such a file
should be compiled and linked in.
So when connected to a D project, compile and link in its .di
file, don't just import it.
2. A D interface file generated (or written) to replace C header
files connected to a C application or project.
There may be missing symbols in using such a file, and because of
1. above, these will NOT be generated by compiling the .di file
and linking it in. Instead those symbols need to be generated by
renaming the file to .d so it is treated as regular D source, as
the C source it refers to, not being D, will not produce those
type-related symbols, so the interface file itself has to do
that. The trickery used to minimize the implied existence of such
type related symbols does not always succeed, e.g. in the case of
doubles in structs.
In summary, always compile and link in a D interface file. If it
is connected to a C project as a D replacement for C header
files, rename the .di file to a .d file and compile and link that.
---curious if there's any disagreement with this, eager to hear
feedback.
R.
