OpenBSD port #5324

abdelq · 2020-05-12T05:15:19Z

First time contribution, a follow-up to #1921. This requires OpenBSD -current or 6.7 (related to #4803), which is slated for release on the 19th. Furthermore, LLVM 10 also needs to be compiled.

Sadly, as it stands, I couldn't get Zig to compile properly (excerpt follows):

[ 98%] Building CXX object CMakeFiles/zig0.dir/src/main.cpp.o
[ 98%] Building CXX object CMakeFiles/zig0.dir/src/stage2.cpp.o
[ 99%] Linking CXX executable zig0
[ 99%] Built target zig0
Scanning dependencies of target zig_build_libstage2
zig0:/usr/lib/../lib/libc++abi.so.2.1: undefined symbol '__sF'
zig0:/usr/lib/../lib/libc++.so.4.0: undefined symbol '__sF'
zig0:/usr/lib/../lib/libm.so.10.1: undefined symbol '_ctype_'
zig0:/usr/lib/../lib/libpthread.so.26.1: undefined symbol '__isthreaded'
zig0:/usr/lib/../lib/libpthread.so.26.1: undefined symbol '_thread_sys_fork'
zig0:/usr/lib/../lib/libpthread.so.26.1: undefined symbol '_thread_sys_vfork'
zig0:/usr/lib/../lib/libcurses.so.14.0: undefined symbol '_ctype_'
zig0:/usr/lib/../lib/libcurses.so.14.0: undefined symbol '__isthreaded'
zig0:/usr/lib/../lib/libcurses.so.14.0: undefined symbol '__sF'
zig0:/usr/lib/../lib/libz.so.5.0: undefined symbol '__isthreaded'
zig0:/usr/lib/../lib/libedit.so.5.2: undefined symbol '__isthreaded'
zig0:/usr/lib/../lib/libedit.so.5.2: undefined symbol '__sF'
zig0:/usr/lib/../lib/libedit.so.5.2: undefined symbol '_ctype_'
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFiRKN4llvm5ErrorEEEE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFyvEEE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFbjRKN4llvm6ModuleEEEE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFN4llvm5ErrorERNS2_11raw_ostreamEEEE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFNS_10unique_ptrIN4llvm3lto18NativeObjectStreamENS_14default_deleteIS5_EEEEjEEE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFvN4llvm13IRBuilderBase11InsertPointEEEE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFvRKN4llvm18PassManagerBuilderERNS2_6legacy15PassManagerBaseEENS_9allocatorISA_EES9_EE) size mismatch, relink your program
zig0:/usr/lib/libLLVM-10.so: /home/julius/zig/build/zig0 : WARNING: symbol(_ZTVNSt3__110__function6__baseIFvvEEE) size mismatch, relink your program
Segmentation fault (core dumped)

Running a debugger yields:

Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Breakpoint 2, issetugid () at -:3
3	in -
(gdb) step

Breakpoint 2, issetugid () at -:3
3	in -
(gdb)
_libc_pthread_self () at /usr/src/lib/libc/thread/rthread.c:105
105	/usr/src/lib/libc/thread/rthread.c: No such file or directory.
	in /usr/src/lib/libc/thread/rthread.c
Current language:  auto; currently minimal
(gdb)
43		__asm__ ("movq %%fs:(%1),%0" : "=r" (val) : "r" (offset));
(gdb)
Die: DW_TAG_unspecified_type (abbrev = 22, offset = 4638166)
	has children: FALSE
	attributes:
		DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"

I've tried a few things to no avail. Looking for other people's input (@mikdusan? @jreut?), hence opening this draft PR.

mikdusan · 2020-05-12T11:57:06Z

zig0:/usr/lib/libLLVM-10.so

First get zig building against static llvm/clang/lld libraries. There are many ways to build llvm and we don't ensure our cmake can deal with them all. It can deal with a minimalist static build of llvm and my brain cannot recall if llvm can be built with both static/dynamic libraries, please don't do so even if llvm allows it.

If it helps, around time of #4803 I have an llvm-tarball that was linking zig0. It's here .

mikdusan · 2020-05-12T12:21:38Z

lib/std/fs.zig

+            var prg_name = argv[0];
+            if (prg_name[0] == '/' or prg_name[0] == '.') {
+                return os.realpathZ(prg_name, out_buffer);
+            }
+            prg_name = mem.spanZ(prg_name);


This code assumes pathname beginning with . is a path component of either . or .. but it could also be a dot-named file. Let's use std.mem.indexOfScalar(..., '/') to detect idx == 0 or "." or ".." here.

mikdusan · 2020-05-12T12:56:39Z

src/os.cpp

+    if (*prg_name == '/' || *prg_name == '.') {
+        buf_init_from_str(tmp, prg_name);
+        return os_path_real(tmp, out_path);
+    } else {


same here. handle 3 cases explicitly as lib/std/fs.zig equivalent

mikdusan · 2020-05-12T13:01:01Z

src/os.cpp

+        // Look for the program in the set of directories
+        char *path, *paths = buf_ptr(tmp);
+        while ((path = strsep(&paths, ":")) != nullptr) {
+            snprintf(out, PATH_MAX, "%s/%s", path, prg_name);


use buf_sprintf instead of snprintf

use memSplit instead of strsep

daurnimator · 2020-05-12T13:05:31Z

lib/std/fs.zig

@@ -1655,6 +1664,48 @@ pub fn selfExePath(out_buffer: *[MAX_PATH_BYTES]u8) SelfExePathError![]u8 {
            // TODO could this slice from 0 to out_len instead?
            return mem.spanZ(@ptrCast([*:0]u8, out_buffer));
        },
+        .openbsd => {
+            // OpenBSD has no support for this. Out of the various tried methods,
+            // the only working workaround comes from stackoverflow.com/a/31495527


It's better to not implement this at all then it is to have a workaround.

andrewrk · 2020-07-05T23:08:48Z

I suggest to take advantage of zig's lazy top level declaration analysis, and the fact that we don't have any OpenBSD CI tests to regress, and break this into a series of smaller changes, landing your progress into master branch. Progress towards another operating system support does not have to be in one giant PR that does everything, you can make progress one piece at a time. This will prevent a situation like this right now, where an entire body of work is abandoned, even though it has plenty of useful changes which could have easily landed in master.

Thanks for your work, I hope we can get some of it landed.

tleguern and others added 11 commits May 11, 2020 21:02

Initial OpenBSD port

e44e9d0

Continuation of the OpenBSD port

6af59c8

Executable path for OpenBSD

e79cba2

Miscellaneous changes

99b99d3

Use arc4random_buf() to implement getrandom() for OpenBSD

563b70c

Dynamic library loading for other BSDs

ebf45d3

Removing DT_WHT from OpenBSD's choice of entry kinds

1416b7d

Prefer getentropy over /dev/urandom on OpenBSD

333e0cb

Version detection for the BSDs

93582e4

Zig version of self executable path for OpenBSD

5b0b9bd

OpenBSD C, OS and bit files

9340e10

abdelq force-pushed the openbsd branch 2 times, most recently from 7225bf1 to 2f5b8ca Compare May 12, 2020 05:56

Fixes

d687230

abdelq force-pushed the openbsd branch from 2f5b8ca to d687230 Compare May 12, 2020 06:03

daurnimator added the os-openbsd label May 12, 2020

mikdusan reviewed May 12, 2020

View reviewed changes

daurnimator reviewed May 12, 2020

View reviewed changes

andrewrk closed this Jul 5, 2020

justjosias mentioned this pull request Jul 22, 2020

Tier 3 OpenBSD Support for x86_64 #2016

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OpenBSD port #5324

OpenBSD port #5324

abdelq commented May 12, 2020 •

edited

Loading

mikdusan commented May 12, 2020

mikdusan May 12, 2020

mikdusan May 12, 2020 •

edited

Loading

mikdusan May 12, 2020 •

edited

Loading

daurnimator May 12, 2020

andrewrk commented Jul 5, 2020

OpenBSD port #5324

OpenBSD port #5324

Conversation

abdelq commented May 12, 2020 • edited Loading

mikdusan commented May 12, 2020

mikdusan May 12, 2020

Choose a reason for hiding this comment

mikdusan May 12, 2020 • edited Loading

Choose a reason for hiding this comment

mikdusan May 12, 2020 • edited Loading

Choose a reason for hiding this comment

daurnimator May 12, 2020

Choose a reason for hiding this comment

andrewrk commented Jul 5, 2020

abdelq commented May 12, 2020 •

edited

Loading

mikdusan May 12, 2020 •

edited

Loading

mikdusan May 12, 2020 •

edited

Loading