Nim: Tests failing on MIPS on Debian

[FedericoCeratto]

Nim 0.19.0 fails to build on MIPS.

Current Output

Hint: operation successful (29691 lines compiled; 6.857 sec total; 31.891MiB peakmem; Debug Build) [SuccessX]
Hint: /<<PKGBUILDDIR>>/.cache/nim/times_d/runnableExamples/times_examples6  [Exec]
times_examples6.nim(5)   times_examples6
system.nim(3790)         failedAssertImpl
system.nim(3783)         raiseAssert
system.nim(2830)         sysFatal
Error: unhandled exception: /<<PKGBUILDDIR>>/.cache/nim/times_d/runnableExamples/times_examples6.nim(5, 12) `$utc(fromUnix(0)) == "1970-01-01T00:00:00Z"`  [AssertionError]
Error: execution of an external program failed: '/<<PKGBUILDDIR>>/.cache/nim/times_d/runnableExamples/times_examples6 '
[Examples] failed: see /<<PKGBUILDDIR>>/.cache/nim/times_d/runnableExamples/times_examples6.nim

[skilchen]

The problem is that the conversion to byte at compiletime doesn't work the same on Debian MIPS as on other systems. Something like:

static:
  var a = "abc"
  for c in a:
    echo c.byte

produces:

0
0

on Debian MIPS

The following patch probably would fix the problems with times.nim on Debian MIPS (without harming other systems):

diff --git a/lib/pure/times.nim b/lib/pure/times.nim
index ae412ea..4406737 100644
--- a/lib/pure/times.nim
+++ b/lib/pure/times.nim
@@ -1720,15 +1720,15 @@ proc initTimeFormat*(format: string): TimeFormat =
     of tkLiteral:
       case token
       else:
-        result.patterns.add(FormatPattern.Lit.byte)
+        result.patterns.add(ord(FormatPattern.Lit).byte)
         if token.len > 255:
           raise newException(ValueError,
                              "Format literal is to long:" & token)
         result.patterns.add(token.len.byte)
         for c in token:
-          result.patterns.add(c.byte)
+          result.patterns.add(ord(c).byte)
     of tkPattern:
-      result.patterns.add(stringToPattern(token).byte)
+      result.patterns.add(ord(stringToPattern(token)).byte)

My qemu based Debian MIPS emulator is just too slow to run the Nim test suite locally. So you have to try it yourself.

[FedericoCeratto]

Related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919398

[glaubitz]

This issue is also present on powerpc, ppc64 and sparc64, so it's not architecture-specific.

It could be related to the fact that all of these architectures are big-endian and the Nim code in question isn't endianness-agnostic.

@skilchen You can get access to sparc64 porterbox through the gcc compile farm: https://gcc.gnu.org/wiki/CompileFarm

[narimiran]

@FedericoCeratto @glaubitz is this still a problem with Nim 1.0.6?

[glaubitz]

I just tried building Nim from git on MIPS (big-endian) and the build failed with:

CC: linenoise
CC: stdlib_assertions.nim
/bin/sh: 1: mips-openwrt-linux-gcc: not found
Error: execution of an external compiler program 'mips-openwrt-linux-gcc -c  -w -pthread -O3 -fno-strict-aliasing -fno-ident  -I/home/glaubitz/Nim/lib -I/home/glaubitz/Nim/nimsuggest -o /home/glaubitz/.cache/nim/nimsuggest_r/linenoise.c.o /home/glaubitz/Nim/lib/wrappers/linenoise/linenoise.c' failed with exit code: 127


/bin/sh: 1: mips-openwrt-linux-gcc: not found
FAILURE

Looks like Nim has the compiler triplet hard-coded to be OpenWRT (or the autodetection is unreliable).

[genotrance]

Probably related to https://github.com/nim-lang/Nim/pull/13591.

[narimiran]

Probably related to #13591.

...which is now merged.
@glaubitz wanna give it another try?

[FedericoCeratto]

@narimiran the mipsel and mips64el tests has been succeeding for a good while:
https://buildd.debian.org/status/logs.php?pkg=nim&arch=mipsel
https://buildd.debian.org/status/logs.php?pkg=nim&arch=mips64el

[glaubitz]

Are we talking about mipsEL or mips?

[FedericoCeratto]

mipsel and mips64el, since the big endian mips has been discontinued in 2019. I suppose probably no other distribution actively supports it at this point.

[glaubitz]

On Mar 12, 2020, at 1:25 AM, Federico Ceratto [e-mail] wrote:


mipsel and mips64el, since the big endian mips has been discontinued in 2019. I suppose probably no other distribution actively supports it at this point.

That’s not true. mips was removed from unstable. However, mips is still supported in Buster, hence it’s effectively not discontinued.

Plus, fixing such bugs always makes sense as the problem could show underlying issues. I have run a test build on the porterbox minkus, will check back later to see if it was successful.

[FedericoCeratto]

mips is still supported in Buster

I'm aware of that. Dropping MIPS in Unstable is described as "discontinued" in https://wiki.debian.org/MIPSPort and now the buildbots are not running builds on it.
Anyhow I'm all in favor of fixing the build on MIPS as well if it can be helpful.

[glaubitz]

I'm aware of that. Dropping MIPS in Unstable is described as "discontinued" in https://wiki.debian.org/MIPSPort and now the buildbots are not running builds on it.

They are building it for anything that is not unstable.

Also, we can rebootstrap any architecture any time we want thanks to the efforts of Helmut Grohne.

[glaubitz]

Oh, and I ran sh ./build_all.sh && ./koch doc && ./koch tests on minkus (a Debian MIPS big-endian porterbox) and it finished without any errors after the fix from #13591.

[narimiran]

Great, then we can close this, right?