• d-bugmail puremagic.com (39/39) Jan 08 2023 https://issues.dlang.org/show_bug.cgi?id=23608

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=23608

          Issue ID: 23608
           Summary: [musl 32-bit] Time functions linked incorrectly on
                    musl >=1.2.0 / 32-bit
           Product: D
           Version: D2
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: regression
          Priority: P1
         Component: druntime
          Assignee: nobody puremagic.com
          Reporter: dlang-bugzilla thecybershadow.net

(copied from PR)

musl switched to 64-bit time_t across all architectures in version 1.2.0:

https://musl.libc.org/time64.html

This change was done in a way which attempted to preserve ABI compatibility. To
achieve this, the 32-bit versions of functions were left at their original
names in the compiled library, and new 64-bit versions of functions were
introduced. The header files then redirected calls to the standard function
names to use the new 64-bit versions using the `__asm__("name")` construct,
which is similar to D's `pragma(mangle, "name")`.

Commit ca0b670b87284afa341f1bef57f5614d88aecb4b tried addressing this change in
musl by changing time_t to 64-bit when targeting new musl versions (the
default). However, that change was incomplete, as it did not implement the
function redirection part of the change, which is required to actually call the
implementations using 64-bit time_t. As a result, it caused programs to link
but return incorrect results at runtime on 32-bit architectures when targeting
new musl versions.

I'm guessing what was fixed by that change is not interop between D and the
musl libc, but between D and other C libraries which use the definition of
`time_t` from the libc. https://github.com/dlang/druntime/pull/3275 causes
Druntime to divide by zero at startup
(https://github.com/dlang/dmd/blob/3368127d1a59ac1a7c95cf46a1c93a0ea73d665a/druntime/src/core/time.d#L2852)
- because we are calling `clock_getres` with the expectation that it populates
a `timespec` with 64-bit `time_t`, but we are actually calling the 32-bit
version, so `ts.tv_nsec` remains at the default-initialized 0 value.

--