NQP no longer builds on OpenBSD post Mar 24 (bisected on NQP)

[stmuk]

NQP no longer builds on OpenBSD

Bisected on NQP to MoarVM bump of

Raku/nqp@aa605d0

Error

[..snip..]

perl tools/build/gen-cat.pl moar src/core/NativeTypes.nqp  src/core/NQPRoutine.nqp  src/core/NQPMu.nqp  src/core/NQPCapture.nqp  src/cor
e/IO.nqp  src/core/Regex.nqp  src/core/Hash.nqp  src/core/NQPLock.nqp  src/core/testing.nqp  src/core/YOUAREHERE.nqp   > gen/moar/stage1
/NQPCORE.setting
/home/steve/sandbox/rakudo/install/bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --module-path=gen/moa
r/stage1 --setting=NULL --no-regex-lib --target=mbc --stable-sc=stage1  --output=gen/moar/stage1/NQPCORE.setting.moarvm gen/moar/stage1/
NQPCORE.setting
SC not yet resolved; lookup failed
   at src/vm/moar/ModuleLoader.nqp:61  (src/vm/moar/stage0/ModuleLoader.moarvm:load_module)
 from gen/moar/stage2/NQP.nqp:270  (src/vm/moar/stage0/nqp.moarvm:load_module)
 from gen/moar/stage2/NQP.nqp:2418  (src/vm/moar/stage0/nqp.moarvm:statement_control:sym<use>)
 from gen/moar/stage2/QRegex.nqp:1656  (src/vm/moar/stage0/QRegex.moarvm:!reduce)
 from gen/moar/stage2/QRegex.nqp:1599  (src/vm/moar/stage0/QRegex.moarvm:!cursor_pass)
 from <unknown>:1  (src/vm/moar/stage0/nqp.moarvm:statement_control:sym<use>)
 from gen/moar/stage2/QRegex.nqp:1696  (src/vm/moar/stage0/QRegex.moarvm:!protoregex)
 from <unknown>:1  (src/vm/moar/stage0/nqp.moarvm:statement_control)
 from gen/moar/stage2/NQP.nqp:954  (src/vm/moar/stage0/nqp.moarvm:statement)

[..snip..]

[stmuk]

It seems others have built successfully recently see rakudo/rakudo#1867

I have these patches installed on OpenBSD 6.3

$ sudo syspatch -l
001_perl
002_libtls
003_arp
004_gif
005_httpd
006_ipseclen
007_libcrypto
008_ipsecout
009_libcrypto
010_intelfpu

[Kaiepi]

What flags are you using to build MoarVM?

[jnthn]

Are you building on a big endian platform, by any chance?

[jnthn]

Though I just spotted "intelfpu" in the patch list, so I guess no, so there goes that hypothesis most probably. I guess it's worth asking 32-bit or 64-bit also...

[Kaiepi]

I'm on a little endian x64 system. I have the same patches installed with syspatch.

[stmuk]

@Kaiepi I was just using "perl Configure.pl --gen-moar --make-install" for both rakudo and NQP . Do you have any resource limit tweaks (ulimit, login class etc.)?

@jnthn no just amd64

[Kaiepi]

I was able to reproduce this error. Building with --moar-option=--cc=egcc seems to mitigate it for now

[stmuk]

See http://colabti.org/irclogger/irclogger_log/perl6-dev?date=2018-06-22#l168

Summary is this seems to be related to compiler version.

The original error can be reproduced by using the standard ancient patched gcc 4.2.1 which ships with OpenBSD whereas an externally installed (from ports) gcc 4.9.2 works.

OpenBSD also ships clang as standard and are slowly moving towards its use so maybe our configure scripts should end up using that long term?

[ugexe]

Might be worth a shot to update libuv to its latest version as it has at least one new glibc workaround for ancient versions.

[stmuk]

@ugexe OpenBSD uses its own libc and not glibc so its unlikely to help in this particular case although it may help in others.

[samcv]

Clang may be a good choice if that version is more recent than the gcc version is.