- changed status to open
build fails on OpenBSD/386
Original issue 322 created by inferno-os on 2015-02-28T15:48:04.000Z:
$ uname -a OpenBSD callisto.local 5.6 GENERIC.MP# 0 i386
I start building after changing mkconfig for OpenBSD and 386:
- $ /makemk.sh && mk -s nuke mkdirs install
- [...]
- gcc -c -I/home/user/inferno/OpenBSD/386/include -I/home/user/inferno/include -I/home/user/inferno/utils/include Posix.c sh.c arc.c archive.c bufblock.c env.c file.c graph.c job.c lex.c main.c match.c mk.c parse.c recipe.c rule.c run.c shprint.c symtab.c var.c varsub.c word.c
- main.c: In function 'main':
- main.c:27: warning: return type of 'main' is not 'int'
- run.c: In function 'sched':
- run.c:74: warning: passing argument 1 of 'time' from incompatible pointer type
- run.c: In function 'usage':
- run.c:283: warning: passing argument 1 of 'time' from incompatible pointer type
- gcc -o mk Posix.o sh.o arc.o archive.o bufblock.o env.o file.o graph.o job.o lex.o main.o match.o mk.o parse.o recipe.o rule.o run.o shprint.o symtab.o var.o varsub.o word.o /home/user/inferno/OpenBSD/386/lib/libregexp.a /home/user/inferno/OpenBSD/386/lib/libbio.a /home/user/inferno/OpenBSD/386/lib/lib9.a
- Posix.o(.text+0x97b): In function `maketmp':
-
- warning: tmpnam() possibly used unsafely; consider using mkstemp()
- env.o(.text+0x4bb): In function `buildenv':
-
- warning: strcpy() is almost always misused, please use strlcpy()
- /home/user/inferno/OpenBSD/386/lib/libregexp.a(regcomp.o)(.text+0x2e1): In function `cant':
- warning: strcat() is almost always misused, please use strlcat() mk binary built successfully!
The mk binary is built, but core dumps on execution:
$ mk install Abort trap (core dumped)
Changing long to time_t in utils/mk/run.c (line 71 and 281) produces a usable mk binary (OpenBSD uses a 64-bit value for time_t, since version 5.5). During mk install, it throws a variety of warnings, but most things get compiled. It produces some errors in the end on rfork_thread(), which returns pid in kproc() @ emu/OpenBSD/os.c, line 251:
$ ./makemk.sh && mk -s nuke mkdirs install [...] (cd emu; mk -s install) (cd OpenBSD; mk -s install) cc -c asm-386.S cc -c -DROOT="/home/user/inferno" -DEMU -I. -I../port -I/home/user/inferno/OpenBSD/386/include -I/home/user/inferno/include -I/home/user/inferno/libinterp -g -O -Wno-deprecated-declarations -Wuninitialized -Wunused -Wreturn-type -Wimplicit -I/home/user/inferno/OpenBSD/386/include -I/home/user/inferno/include -I/usr/X11R6/include -DOPENBSD_386 -fno-stack-protector os.c os.c: In function 'kproc': os.c:251: error: 'RFPROC' undeclared (first use in this function) os.c:251: error: (Each undeclared identifier is reported only once os.c:251: error: for each function it appears in.) os.c:251: error: 'RFMEM' undeclared (first use in this function) os.c:251: error: 'RFNOWAIT' undeclared (first use in this function) mk: cc -c -DROOT="/home/user/inferno" ... : exit status=exit(1) mk: echo "(cd $SYSTARG; ... : exit status=exit(1) mk: for j in ... : exit status=exit(1)
Seems rfork was removed from OpenBSD a while ago (april 12, 2012 - https://www.mail-archive.com/misc@openbsd.org/msg111497.html).
It looks like emu/OpenBSD/os.c needs to be changed, but I'm not sure how to replace the rfork_thread function. Tried a few things but none of them worked.
Comments (2)
-
-
I've provided a PR to fix this, that adopts the pthreads solution suggested.
- Log in to comment
As it happens, all the mk code needs to do is avoid the cast and the compiler will convert 0 to the right parameter type.
The rfork change is more complicated. It needs to use "__tfork", but the implications of using "threads" instead of processes are a little more involved. It might be better to use their pthreads library via kproc-pthreads.c, as on Linux (for similar reasons). I can't tell off-hand whether that should be pthreads or rthreads. If pthreads uses __tfork, then the existing pthreads implementation of kproc in port might work, just as it's now used by the Linux port instead of using __clone directly for similar reasons. The overhead for a kproc is higher, but it probably doesn't matter for most applications.