I think I understand what's going on. In mscoffobj.d, the code uses time(&f_timedat) to grab the current time and stick it in the object file header. That's why we get different binaries when compiling the same code at different times.

I'd like to fix this, but I'm not sure which way to go. Like, we can just use a fixed value like 0 for the timestamp. This definitely makes builds deterministic. I tried this thing and compiled same code at different times, and the object file was the same hash.

abulk@MSI MINGW64 ~/OneDrive/Desktop/hash
$ certutil -hashfile prog1.obj SHA256
SHA256 hash of prog1.obj:
52b8e353dd0a057a1ddd44af9c1bdb7154bf14a27ccda82b71c856a5f9e9d4ff
CertUtil: -hashfile command completed successfully.

abulk@MSI MINGW64 ~/OneDrive/Desktop/hash
$ certutil -hashfile prog2.obj SHA256
SHA256 hash of prog2.obj:
52b8e353dd0a057a1ddd44af9c1bdb7154bf14a27ccda82b71c856a5f9e9d4ff
CertUtil: -hashfile command completed successfully.

But is it the right approach to tackle this issue or maybe like we need to create some kind of hash based on what's in the object file?

I would love to hear your suggestions.

Just use TimeStampInfo from the frontend: #11035

@Geod24 Did u mean like this?

    time_t f_timedat;
    const(char)* source_date_epoch = getenv("SOURCE_DATE_EPOCH");
    if (source_date_epoch)
    {
        // Convert from string to time_t value
        f_timedat = cast(time_t)strtoul(source_date_epoch, null, 10);
    }

That was my first idea as well, but I don't like how you have to set an environment variable to make builds reproducible even if you don't use __TIMESTAMP__ and the like. Moreover, you'd manually need to change that variable along with your source changes or the loader won't behave correctly:

The timestamp is really a unique ID that tells the loader, “The exports of this DLL have not changed since the last time anybody bound to it"

I'd rather follow Microsoft's example here and hash the binary.