Linkage problem with D interface files used in place of C headers when structs contain doubles.

[Rambutan001]

I ran into a linkage problem using a big D interface file to work with a big C project. In a nutshell, if a struct containing a double is in a C compatible D interface file then allocating that struct with new in a D module that imports the D interface in that file causes a linkage error, seeking xtoHash and xopEquals for that struct. (I'm using gdc, but presumably the problem is over here too.)

Provided =void is attached to every struct member in the interface file, it can be imported without difficulty into D modules without ever being compiled, excepting only so far as I know when a double is a struct member.

I wrote a toy version of the problem, apart from =void see here for actual details of the above.
https://forum.dlang.org/post/crrjqrskndpvptbtpetf@forum.dlang.org

It seems a D interface file cannot be used in this simplistic way to give types in a C project as a replacement for the header files in that project which cannot be used in D source.

Also, if the D interface file itself is compiled and the resulting object included in the project's build, it does not provide the necessary xtoHash and xopEquals to resolve the linkage problem. (Renaming as a D source file by changing the extension from .di to .d resolves the problem, so there is an operational solution.)

Is it me, or is this linkage problem a bug! Since equality of doubles isn't just bitwise equality, hashing or comparing (for equality) structs containing a double is subtle, so plainly for use in D those special methods are necessary. The linkage error can be avoided if the struct containing a double is allocated with say GC.calloc, but presumably this just defers the problem.

A D interface file is for interface to compiled D code it seems, where xtoHash and xopEquals would be present for such a struct. It's not really able to be a C interface file for D, unless this issue with doubles can be solved.

[Herringway]

Reduced further:
di.di

struct b_real {
	double val;
}

main.d

import di;
int main() { return 0; }

b_real* alcb_real(double x) {
	return new b_real;
}

I notice that the results are identical if the di.di file is renamed to di.d and omitted from the compiler invocation (ie dmd main.d instead of dmd main.d di.di). Are .di files specified on the command line simply ignored by the compiler?

[Rambutan001]

Compiling the .di file separately does produce an object, but it is smaller that compiling it renamed with extension .d and does not include the necessary xtoHash and xopEquals to link. The compilation of .di files seems to assume such a file summarizes what's in some D source file of the same name with extension .d in the project where e.g. the necessary xtoHash and xopEquals are actually implied compiled, so those symbols are not to be generated twice. This my current thinking, in line with new posts at the forum.
https://forum.dlang.org/post/117pg5r$1n61$1@digitalmars.com

Your further condensation omits a miniature version of the intended purpose, and I would not expect a .di file not intended by various techniques to represent C datatypes to not need linkage, as per the preceding paragraph indicating my updated thinking.

As per the forum, if you put double val=void; in your struct definition in di.di then you block needing an initializer at link time. This =void completely avoids linkage problems for all types of members excepting those involving double it seems. Those still need xtoHash and xopEquals.

[Rambutan001]

OK, so is it a bug? Any opinions?

[ibuclaw]

Are .di files specified on the command line simply ignored by the compiler?

They are used only for semantic analysis, not code generation.

.di files are used to expose the API (but not the implementation) of a D library. They still require that the object file(s) from the .d sources they're interfacing to be linked in.

.di files aren't meant as interfaces to C libraries. It can be done that way, but the moment you start using features that require RTTI, then you run into link-time errors as you've found.

Better to always name the D modules .d, regardless of whether they provide bindings or implementation.