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