Testament: build fails on 32-bit musl libc because d:nimUse64BitCTime isn't passed to compiler

[tokyovigilante]

Description

Musl defines time_t as a 64 bit int on all platforms. When building against Musl (Alpine linux in this case) the build fails on 32-bit platforms because the nimUse64BitCTime flag isn't passed when building testament.

Example (from Alpine's CI - https://gitlab.alpinelinux.org/tokyovigilante/aports/-/jobs/1565125):

Nim Version

2.2.0

Current Output

/home/buildozer/.cache/nim/testament_r/@m..@slib@spure@stimes.nim.c: In function 'getLocalOffsetAndDst__pureZtimes_u1906':
/home/buildozer/.cache/nim/testament_r/@m..@slib@spure@stimes.nim.c:2179:28: error: passing argument 1 of 'localtime' from incompatible pointer type [-Wincompatible-pointer-types]
 2179 |         tmPtr = localtime((&a));
      |                           ~^~~
      |                            |
      |                            long int *
In file included from /home/buildozer/.cache/nim/testament_r/@m..@slib@spure@stimes.nim.c:11:
/usr/include/time.h:60:23: note: expected 'const time_t *' {aka 'const long long int *'} but argument is of type 'long int *'
   60 | struct tm *localtime (const time_t *);
      |                       ^~~~~~~~~~~~~~
CC: ../lib/pure/concurrency/cpuinfo.nim
CC: ../lib/std/monotimes.nim
Error: execution of an external compiler program 'gcc -c  -w -fmax-errors=3 -pthread -O3 -fno-strict-aliasing -fno-ident -fno-math-errno   -I/builds/tokyovigilante/aports/community/nim/src/nim-2.2.0/lib -I/builds/tokyovigilante/aports/community/nim/src/nim-2.2.0/testament -o /home/buildozer/.cache/nim/testament_r/@m..@slib@spure@stimes.nim.c.o /home/buildozer/.cache/nim/testament_r/@m..@slib@spure@stimes.nim.c' failed with exit code: 1
FAILURE

Expected Output

No response

Known Workarounds

Force 64-bit time_t by patching nim_posix_other.nim.

Additional Information

No response

[tokyovigilante]

Actually this can be resolved by also passing the nimUse64BitCTime to koch when building tools. Sorry this isn't actually a bug, closing.

[tokyovigilante]

In fact this also affects the test runner, specifically nimexec "cc --opt:speed testament/testament" does not get passed the nimUse64BitCTime flag.

[ringabout]

Would you mind trying the devel branch(after #24313) ?

[tokyovigilante]

Thanks, have just tried wth 2c56872 but get the following (on x86):

alpine-x86:~/nim$ ./build_all.sh
bin/nim_csources_86742fb02c6606ab01a532a0085784effb2e753e exists.

cmd: rm -f bin/nim

cmd: cp bin/nim_csources_86742fb02c6606ab01a532a0085784effb2e753e bin/nim

cmd: bin/nim_csources_86742fb02c6606ab01a532a0085784effb2e753e -v
Nim Compiler Version 1.9.1 [Linux: i386]
Compiled at 2023-01-02
Copyright (c) 2006-2022 by Andreas Rumpf

git hash: 7f6681b4c4ccc0dc43fd256280be4c3ad3c773e5
active boot switches: -d:release -d:danger

cmd: bin/nim c --noNimblePath --skipUserCfg --skipParentCfg --hints:off koch
/home/ryan/nim/tools/deps.nim(1, 11) Warning: imported and not used: 'strutils' [UnusedImport]

cmd: ./koch boot -d:release --skipUserCfg --skipParentCfg --hints:off
deps.cmd: git checkout -q bd9bf4eaea124bf8d01e08f92ac1b14c6879d8d3
iteration: 1
bin/nim c  --skipUserCfg --skipParentCfg -d:nimKochBootstrap --nimcache:nimcache/r_linux_i386 -d:release --skipUserCfg --skipParentCfg --hints:off --noNimblePath --compileOnly compiler/nim.nim
/home/ryan/nim/compiler/modulegraphs.nim(14, 11) Warning: imported and not used: 'algorithm' [UnusedImport]
/home/ryan/nim/compiler/ccgtypes.nim(1020, 14) Error: type mismatch: got <string, name: Rope, len: BiggestInt, void>
but expected one of:
template addArrayTypedef(builder: var Builder; name: string; len: int;
                         typeBody: typed)
  first type mismatch at position: 3
  required type for len: int
  but expression 'len = n' is of type: BiggestInt

expression: addArrayTypedef(typedef, name = result, len = n) do:
  typedef.add(e)
FAILURE

[ringabout]

Yeah, it's an error reported by #24347 should be fixed by #24348

[tokyovigilante]

Oh nice, just patched that in and have made it all the way through the build, and running the tests now, so that looks like a good fix. Thanks!

[ringabout]

No problem!