initial support for haiku #7546

hoanga · 2020-12-25T14:17:28Z

seasons greetings zig community!

the following PR adds initial support for getting zig to build stage1 on Haiku. i have confirmed it compiles zig and zig0 and also still builds on other OSes (tested on mac).

the following is a short excerpt of building (requires llvm11)

~/src/git/zig/build> make                      
[  4%] Built target zigcpp                                      
[ 81%] Built target embedded_softfloat                             
[ 83%] Built target opt_c_util                              
[ 97%] Built target zigstage1
[ 99%] Built target zig0
[ 99%] Building self-hosted component /boot/home/src/git/zig/build/zig1.o
[ 99%] Linking CXX executable zig
[100%] Built target zig

~/src/git/zig/build> uname -a
Haiku shredder 1 hrev54798 Dec 19 2020 08:17:11 x86_64 x86_64 Haiku

~/src/git/zig/build> /boot/home/src/git/zig/build/zig env
{
 "zig_exe": "/boot/home/src/git/zig/build/zig",
 "lib_dir": "/boot/home/src/git/zig/lib",
 "std_dir": "/boot/home/src/git/zig/lib/std",
 "global_cache_dir": "/boot/home/config/cache/zig",
 "version": "0.7.1+9f3398411"
}

there are some pieces that could use a little more polish but wanted to submit a rough working version for review and suggestions on if the PR can be made more modular or cleaner to merge.

some things i know that could be a little better and will see about getting them fixed when i have some more time if possible (suggestions / help would be welcome)

stub code areas could use more functional versions
make install still won't work as-is (see below)
could not compile using Debug mode (used Release)
need to compile llvm for Haiku


~/src/git/zig/build> make install
[  4%] Built target zigcpp
[ 81%] Built target embedded_softfloat
[ 83%] Built target opt_c_util
[ 97%] Built target zigstage1
[ 99%] Built target zig0
[100%] Built target zig
Install the project...
-- Install configuration: "Release"
-- Installing: /boot/home/src/git/zig/build/bin/zig
-- Set runtime path of "/boot/home/src/git/zig/build/bin/zig" to ""
-- Installing: /boot/home/src/git/zig/build/lib
error: Unexpected
::
:: ERROR: 1
:: (execute_process)
::
:: argv: /boot/home/src/git/zig/build/zig build --override-lib-dir /boot/home/src/git/zig/lib -Dlib-files-only --prefix /boot/home/src/git/zig/build -
Dconfig_h=/boot/home/src/git/zig/build/config.h install
::
:: argv[0]: /boot/home/src/git/zig/build/zig
:: argv[1]: build
:: argv[2]: --override-lib-dir
:: argv[3]: /boot/home/src/git/zig/lib
:: argv[4]: -Dlib-files-only
:: argv[5]: --prefix
:: argv[6]: /boot/home/src/git/zig/build
:: argv[7]: -Dconfig_h=/boot/home/src/git/zig/build/config.h
:: argv[8]: install
::
CMake Error at /boot/home/src/git/zig/cmake/install.cmake:36 (message):
Call Stack (most recent call first):
  cmake_install.cmake:73 (include)


Makefile:114: recipe for target 'install' failed
make: *** [install] Error 1

hoanga · 2020-12-25T14:50:46Z

archive of patches that can be applied to llvm to get it to build for haiku (can apply llvm in zig-bootstrap)

llvm-patches.zip

lib/std/c/haiku.zig

LemonBoy · 2020-12-25T17:31:18Z

lib/std/c/haiku.zig

+pub extern "c" fn getdents(fd: c_int, buf_ptr: [*]u8, nbytes: usize) usize;
+
+pub const dl_iterate_phdr_callback = fn (info: *dl_phdr_info, size: usize, data: ?*c_void) callconv(.C) c_int;
+//pub extern "c" fn dl_iterate_phdr(callback: dl_iterate_phdr_callback, data: ?*c_void) c_int;


Remove this.

lib/std/c/haiku.zig

lib/std/debug.zig

LemonBoy · 2020-12-25T17:34:19Z

lib/std/debug.zig

@@ -1677,6 +1692,17 @@ pub const ModuleDebugInfo = switch (builtin.os.tag) {
            unreachable;
        }
    },
+    .haiku => struct {
+        // Haiku should implement dl_iterat_phdr (https://dev.haiku-os.org/ticket/15743)


Not really, see above.

for the time being, i have backed out most of the changes except for more minimal stub logic for debug and will try to tackle this as a separate item (per above)

lib/std/debug.zig

LemonBoy · 2020-12-25T17:36:05Z

lib/std/fs.zig

+                //const name = @ptrCast([*]u8, "placeholder-please-implement-me");
+                //const name = "placeholder-please-implement-me";
+                return Entry{
+                    .name = base64_alphabet,


i've updated the logic (hopefully with something slightly less worse)

lib/std/os.zig

LemonBoy · 2020-12-25T17:38:40Z

lib/std/process.zig

@@ -775,6 +775,19 @@ pub fn getSelfExeSharedLibPaths(allocator: *Allocator) error{OutOfMemory}![][:0]
            }
            return paths.toOwnedSlice();
        },
+        // Haiku should implement dl_iterat_phdr (https://dev.haiku-os.org/ticket/15743)


andrewrk · 2020-12-25T21:51:59Z

Season's greetings from the Zig project to the Haiku project! Thanks for the patches!

marler8997 · 2020-12-27T03:26:56Z

Seeing this PR begs the question, what criteria does Zig use to support platforms in the standard library?

hoanga · 2020-12-29T05:38:56Z

thank you for the detailed review of the PR. i have pushed updates that hopefully addresses a good portion of the suggestions posted. i have tried to focus on ensuring it can at least build on Haiku and leave the fun parts for later adventures.

after some more tinkering with the build as is on Haiku things i was able to confirm:

it still builds and hopefully doesn't break other platforms
make install still doesn't work
was able to play around with some of the commands zig targets, zig run and zig fmt and confirm they are somewhat functional
zig build still needs some more work
zig zen runs beautifully :)

waddlesplash

Haiku developer here. Always exciting to see new languages add support for Haiku ... and especially when the code was not written by one of the usual HaikuPorts crew, to boot!

waddlesplash · 2021-01-12T15:14:26Z

lib/std/fs/get_app_data_dir.zig

@@ -56,6 +56,13 @@ pub fn getAppDataDir(allocator: *mem.Allocator, appname: []const u8) GetAppDataD
            };
            return fs.path.join(allocator, &[_][]const u8{ home_dir, ".local", "share", appname });
        },
+        .haiku => {
+            const home_dir = os.getenv("HOME") orelse {


Haiku applications should store their data in ~/config/settings, which you can determine by using the find_directory API.

see 3 lines below where they are creating the path ~/config/settings

But yes, it looks like find_directory would be the more official API

i have added in a very bare-bones implementation using the find_directory() as suggested.

waddlesplash · 2021-01-12T15:16:44Z

lib/std/os/bits/haiku.zig

+const std = @import("../../std.zig");
+const maxInt = std.math.maxInt;
+
+// See https://svnweb.freebsd.org/base/head/sys/sys/_types.h?view=co


This looks like a copy/paste error. (Haiku's equivalent types are defined in sys/types.h.)

waddlesplash · 2021-01-12T15:20:32Z

lib/std/process.zig

@@ -775,6 +775,24 @@ pub fn getSelfExeSharedLibPaths(allocator: *Allocator) error{OutOfMemory}![][:0]
            }
            return paths.toOwnedSlice();
        },
+        // revisit if Haiku implements dl_iterat_phdr (https://dev.haiku-os.org/ticket/15743)


You could also submit a patch to Haiku implementing it ;)

Otherwise, yes, get_next_image_info is the way to go.

thanks for the invitation :) and might consider it in the future if someone else doesn't beat me to it. for the nearer term, i prefer to keep my focus on having something that can get this in a better compiling state on Haiku

waddlesplash · 2021-01-12T15:21:09Z

lib/std/target.zig

@@ -1501,6 +1505,10 @@ pub const Target = struct {
            .other,
            => return result,

+            // Operating systems in this list have been verified as not having a standard
+            // dynamic linker path.


Looks like a copy/paste error?

yes, updated with hopefully a better note.

waddlesplash · 2021-01-12T15:21:47Z

lib/std/target.zig

@@ -1501,6 +1505,10 @@ pub const Target = struct {
            .other,
            => return result,

+            // Operating systems in this list have been verified as not having a standard
+            // dynamic linker path.
+            .haiku => return copy(&result, "/system/runtime_loader"),


FWIW, while this is correct at the present time, in the future when/if Haiku introduces proper multiarch (i.e. 32-bit on 64-bit) support, there will be multiple dynamic linkers for each arch, and invoking the wrong one will probably cause problems.

So should this follow the pattern above (in e.g. linux) of .haiku => switch (self.cpu.arch) {?

for the time being i have left a note regarding multiarch support.

waddlesplash · 2021-01-12T15:23:38Z

lib/std/thread.zig

@@ -484,6 +484,9 @@ pub const Thread = struct {
            };
            return @intCast(usize, count);
        }
+        if (std.Target.current.os.tag == .haiku) {


You can get this either via get_system_info (a Haiku-specific API), or via sysconf(_SC_NPROCESSORS_CONF) (which probably works on other OSes, too.)

waddlesplash · 2021-01-12T15:24:41Z

lib/std/c/haiku.zig

+
+pub const _errno = _errnop;
+
+pub extern "c" fn _kern_read_dir(fd: c_int, buf_ptr: [*]u8, nbytes: usize, maxcount: u32) usize;


_kern... functions are syscall hooks, and we make no guarantees whatsoever about their ABIs, which are subject to change without notice, etc. (Calling syscalls via hooks is at least better than by number, though, as the numbers are generated at build time and so change whenever syscalls are touched in pretty much any way.)

thanks! i will keep that in mind, i think some of these exposed syscall hooks might not be as necessary when dl_iterat_phdr support is available

waddlesplash · 2021-01-12T15:28:10Z

lib/std/fs.zig

+                        continue :start_over;
+                    }
+
+                    // TODO: determine entry kind


You can do this by masking the mode using S_IFMT and then checking the type (S_IFDIR etc.)

that helps, thanks :)

waddlesplash · 2021-01-12T15:30:46Z

make install still doesn't work

If this is because of "read-only file system" errors, you will need to adjust your install paths to put things in /system/non-packaged instead, as the /system hierarchy itself is a union-mount of the installed/activated packages. Most software on Haiku is distributed as HPKGs built via HaikuPorter; you can of course make them "manually" via the package tool, as well.

daurnimator · 2021-01-12T15:42:43Z

@waddlesplash what is the status of "libbe.so" on haiku (which is where I see find_directory is documented as belonging to)? is it a base part of the system as much as libc is? Should it be considered an extension of libc? Or is libc on top of it?

waddlesplash · 2021-01-12T15:55:57Z

libbe.so is part of the official Haiku API, yes. It contains most of the "Kits" (Application Kit, Interface Kit, etc.) used in developing GUI applications on Haiku. libroot.so is what contains the libc, and libbe.so is implemented on top of that, not the other way around, of course. But yes, libbe.so is definitely part of the base system and will always be around.

There has been discussion of breaking up libbe.so into separate libraries (having most of the GUI-related kits be in libbe.so is a holdover from BeOS), but that is a long way off to say the least.

waddlesplash · 2021-01-12T16:02:38Z

Actually, the documentation page is just wrong, find_directory is actually in libroot.so. So that is all a moot point.

andrewrk · 2021-01-12T22:10:42Z

lib/std/thread.zig

@@ -484,6 +484,9 @@ pub const Thread = struct {
            };
            return @intCast(usize, count);
        }
+        if (std.Target.current.os.tag == .haiku) {
+            return 1;        // TODO:  implement me


Please remove all bugs such as this from this pull request. You can replace this with

Suggested change

return 1; // TODO: implement me

@panic("TODO implement std.Thread.cpuCount for Haiku");

Or better yet:

Suggested change

return 1; // TODO: implement me

@compileError("TODO implement std.Thread.cpuCount for Haiku");

No wrong implementations please!

makes sense, and have placed in the suggestions in (hopefully) the appropriate places. might have implemented some parts in other areas which hopefully also addresses the problematic code spots

hoanga · 2021-01-16T04:44:27Z

Lots of feedback! Appreciate all of the helpful comments. I will be going over the suggestions and work on getting the PR in a more ready state. Hopefully will have something ready soon!

hoanga · 2021-01-17T22:18:30Z

i have pushed more updates that should handle feedback up to this point and still am trying to stick with the goal of compiling under Haiku.

i have separated out the changes for debug and plan to defer that for later efforts

update on what i was able to confirm:

still building and hopefully isn't breaking on other platforms
zig zen still is okay but previous noted behaviors still appear to be there
make install still isn't available but the zig binary does build

thanks again for the feedback!

andrewrk · 2021-02-25T06:45:00Z

Seeing this PR prompts the question, what criteria does Zig use to support platforms in the standard library?

Part of it is whether an active person is around to do the labor, and the other part of it is whether supporting given platform results in any compromises for more mainstream use cases.

In the future, I'd like to investigate OS support via packages; for now we do it by upstreaming into the std lib.

In this specific case, I'm happy to add experimental Haiku support and see where it goes.

@hoanga thanks for your patience on this one. I'm in the process of merging it now.

* remove unused definitions * setup os specific blocks

* add cpu count * use haiku find_directory * add definitions and exports for building in haiku

* no isHaiku() function since there is not more than one os tag that this applies to. * clean up some control flow into a switch * add some TODO comments to investigate panics that suspiciously look like they should be compile errors (see ziglang#363)

LemonBoy reviewed Dec 25, 2020

View reviewed changes

waddlesplash reviewed Jan 12, 2021

View reviewed changes

vazub mentioned this pull request Jan 12, 2021

Tier 3 Support for x86_64-haiku #7691

Open

andrewrk requested changes Jan 12, 2021

View reviewed changes

hoanga force-pushed the haiku-support branch from 70c0055 to 413454d Compare January 17, 2021 19:49

Al Hoang and others added 5 commits February 25, 2021 16:41

initial support for haiku past stage0

025635c

initial support for haiku continue clean up

6b03722

* remove unused definitions * setup os specific blocks

initial support for haiku sync update

c173966

* add cpu count * use haiku find_directory * add definitions and exports for building in haiku

initial support for haiku defer debug

96a08c1

haiku: minor fixups

37a1d08

* no isHaiku() function since there is not more than one os tag that this applies to. * clean up some control flow into a switch * add some TODO comments to investigate panics that suspiciously look like they should be compile errors (see ziglang#363)

andrewrk force-pushed the haiku-support branch from 413454d to 37a1d08 Compare February 25, 2021 23:59

andrewrk merged commit 7edb204 into ziglang:master Feb 26, 2021

rgreenblatt mentioned this pull request Mar 20, 2021

Clean up debug.zig, particularly stack trace formating #8228

Closed

4 tasks


		pub const _errno = _errnop;

		pub extern "c" fn _kern_read_dir(fd: c_int, buf_ptr: [*]u8, nbytes: usize, maxcount: u32) usize;

	return 1; // TODO: implement me
	@panic("TODO implement std.Thread.cpuCount for Haiku");

	return 1; // TODO: implement me
	@compileError("TODO implement std.Thread.cpuCount for Haiku");

initial support for haiku #7546

initial support for haiku #7546

Conversation

hoanga commented Dec 25, 2020 • edited Loading

hoanga commented Dec 25, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hoanga Dec 29, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewrk commented Dec 25, 2020

marler8997 commented Dec 27, 2020

hoanga commented Dec 29, 2020

waddlesplash left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

waddlesplash commented Jan 12, 2021

daurnimator commented Jan 12, 2021

waddlesplash commented Jan 12, 2021

waddlesplash commented Jan 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hoanga commented Jan 16, 2021

hoanga commented Jan 17, 2021

andrewrk commented Feb 25, 2021 • edited Loading

hoanga commented Dec 25, 2020 •

edited

Loading

hoanga Dec 29, 2020 •

edited

Loading

andrewrk commented Feb 25, 2021 •

edited

Loading