On Friday, 3 July 2026 at 01:40:20 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 03/07/2026 7:06 AM, Danny Arends wrote:
# Is import-only |RTInfo| emission expected to work in 2.112,
or is compiling the ImportC unit now required by design
(fallout from the AA/ array-hook templatization)?
No.
If you don't compile a file, you don't get the symbols that it
provides.
This is true for D, as it is C++.
Understood on external symbols, the SDL/Vulkan functions link
fine from their libs compiled by gcc/clang; that was never the
issue. The undefined symbols are dmd's own RTInfoImpl/TypeInfo
for the C structs — D metadata that has no external source, so it
can only come from compiling the ImportC unit.
My includes.c is pure #include glue (no code of its own), yet I'm
forced to compile it as a full TU solely to obtain that D
type-info.This then also lowers the headers' static inline bodies
and pulls in the __builtin_clz/_BitScanReverse intrinsics ImportC
doesn't implement.
Is there a way to get dmd to emit the type-info for imported C
structs *without* compiling their inline bodies / or is compiling
the whole TU (intrinsics and all) the intended cost of using
typeid/GC on ImportC types?
# Is this the same as fixed Issue 10442 <https://bugzilla-
archive.dlang.org/bugs/10442/> ("RTInfo generation can fail
for structs defined in imported modules"), incompletely fixed?
I don't think so. It never should have worked with dmd's
current generation model for TypeInfo.
