On 12/09/2026 2:19 AM, Rambutan wrote:
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.
The file extension is irrelevant. The compiler treats them the same.
The difference is -I/-extI vs being compiled in.
