Compiler Bug using D interface file for its intended purpose
Iain Buclaw
ibuclaw at gdcproject.org
Tue Sep 8 09:43:22 UTC 2026
On Tuesday, 8 September 2026 at 06:31:08 UTC, Rambutan wrote:
> di.di
> ```D
> extern(C):
>
> struct b_real {
> double val;
> }
> ```
Note: D default initializes floating point and character types to
a non-zero mask, which necessitates the need for an `.init`
symbol.
To be compatible with C, use `= void` or `= 0`.
```d
struct b_real {
double val = void;
}
```
> $ gdc -o breal breal.o dmain.o cmain.o #di.o
> /usr/bin/ld: breal.o:(.data.rel.ro+0x28):
> undefined reference to `initializer for di.b_real'
> /usr/bin/ld: breal.o:(.data.rel.ro+0x30):
> undefined reference to `di.b_real.__xtoHash(ref
> const(di.b_real))'
> /usr/bin/ld: breal.o:(.data.rel.ro+0x38):
> undefined reference to `di.b_real.__xopEquals(ref
> const(di.b_real)) const'
> collect2: error: ld returned 1 exit status
>
For the xtoHash and xopEquals functions, don't shy away from
raising a discussion against DMD - defer creating an issue till
later.
https://github.com/dlang/dmd/discussions
https://github.com/dlang/dmd/issues
Without looking (or remembering) I suspect floating point numbers
might have non-trivial hashing requirement for edge cases such as
comparing `+0.0` and `-0,0`.
If it isn't publicly documented, it ought to be mentioned
somewhere.
But it is also true to say that if you are `new`ing the struct on
the GC, then runtime TypeInfo will *always* be pulled in creating
these sorts of dependencies.
Iain.
More information about the D.gnu
mailing list