wmoxam / crystal-openbsd-port

Crystal-lang for OpenBSD

Home Page:http://wmoxam.com/crystal-openbsd.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Build fails on OpenBSD 6.1 without root

felix opened this issue · comments

Thanks for the port, though I have not been able to build it yet. I get an "Invalid memory access (signal 11)" error while building:

$ uname -a
OpenBSD monk.local 6.1 GENERIC.MP#7 amd64
$ pwd
/usr/ports/mystuff/lang/crystal
$ git remote -v
origin  https://github.com/wmoxam/crystal-openbsd-port.git (fetch)
origin  https://github.com/wmoxam/crystal-openbsd-port.git (push)
$ git branch
  master
* openbsd-6.1
$ make clean
===>  Cleaning for crystal-0.22.0
$ make
===> crystal-0.22.0 depends on: bash-* -> bash-4.4.12
===> crystal-0.22.0 depends on: llvm->=4.0.0 -> llvm-4.0.0p2
===> crystal-0.22.0 depends on: gmake-* -> gmake-4.2.1
===> crystal-0.22.0 depends on: libiconv-* -> libiconv-1.14p3
===> crystal-0.22.0 depends on: boehm-gc-* -> boehm-gc-7.6.0
===> crystal-0.22.0 depends on: libevent-* -> libevent-2.0.22p0
===> crystal-0.22.0 depends on: pcre-* -> pcre-8.38p0
===> crystal-0.22.0 depends on: gcc-libs->=4.9,<4.10 -> gcc-libs-4.9.4p4
===>  Verifying specs:  c event_core event_extra gc iconv m pcre pthread z estdc++>=17
===>  found c.89.3 event_core.1.1 event_extra.0.1 gc.4.0 iconv.6.0 m.10.0 pcre.3.0 pthread.23.0 z.5.0 estdc++.17.0
===>  Checking files for crystal-0.22.0
`/usr/ports/distfiles/0.22.0.tar.gz' is up to date.
`/usr/ports/distfiles/crystal-0.22.0-OpenBSD6.1.tar.gz' is up to date.
>> (SHA256) 0.22.0.tar.gz: OK
>> (SHA256) crystal-0.22.0-OpenBSD6.1.tar.gz: OK
===>  Extracting for crystal-0.22.0
===>  Patching for crystal-0.22.0
===>  Configuring for crystal-0.22.0
===>  Building for crystal-0.22.0
clang++ -c -o /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/src/llvm/ext/llvm_ext.o /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/src/llvm/ext/llvm_ex
t.cc `llvm-config --cxxflags`
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
1 warning generated.
clang -c -o /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/src/ext/sigfault.o /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/src/ext/sigfault.c `llvm-co
nfig --cflags`
mkdir /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/.build
clang++ /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/../crystal.o -o /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/.build/crystal -rdynamic  /usr/por
ts/pobj/crystal-0.22.0/crystal-0.22.0/src/ext/sigfault.o /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0/src/llvm/ext/llvm_ext.o `(llvm-config --libs --
system-libs --ldflags 2> /dev/null)` -lstdc++ -lpcre -lgc -lpthread -levent_core -levent_extra -lssl -liconv
/usr/local/lib/libevent_core.so.1.1: warning: warning: random() may return deterministic values, is that what you want?
cd /usr/ports/pobj/crystal-0.22.0/crystal-0.22.0 && gmake deps && CC=clang gmake
Using /usr/local/bin/llvm-config [version=4.0.0]
ar -rcs src/ext/libcrystal.a src/ext/sigfault.o
Using /usr/local/bin/llvm-config [version=4.0.0]
CRYSTAL_CONFIG_PATH=`pwd`/src ./bin/crystal build  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib
Using compiled compiler at .build/crystal
Invalid memory access (signal 11) at address 0x7f7fffbedfd4
[0x537b1f1cde6] __crystal_sigfault_handler +15472326
[0x537b105b75d] __crystal_sigfault_handler +61
[0x539e517c002] ???
gmake: *** [Makefile:114: .build/crystal] Error 11
*** Error 2 in . (Makefile:49 'do-build')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2639 '/usr/ports/pobj/crystal-0.22.0/.build_done')
*** Error 1 in /usr/ports/mystuff/lang/crystal (/usr/ports/infrastructure/mk/bsd.port.mk:2344 'all')

Ah, please ignore the above, running with doas made it work.

@felix Yeah, requiring superuser privileges for a build to succeed on OpenBSD is a recent issue with the compiler itself. I'd like to track that one down

I have re-opened it as a new issue for completeness. Feel free to close it.

@felix This is resource related. Modifying /etc/login.conf to raise limits on datasize-max and stacksize-cur fixed the problem. I'm not certain that any change to stacksize-cur was actually needed