Haiku: add platform support

[jessicah]

Opening an issue to track work on adding platform support for Haiku: https://www.haiku-os.org/.

Any tips on how cross-compiling should work would be appreciated. Am currently starting with './build.sh mono+libs -arch x64 -os haiku -c debug -cross, and slowly adding Haiku targets to build and about to start some work on adding platform support in src/libraries/Common/src/Interop`.

Thus far it hasn't required a functioning cross-compiler yet, have only just started.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[En3Tho]

What are benefits of having Haiku as an os target vs other os'es?

[am11]

Here is a quick list without debugging shell or cmake scripts / how-to-get-there steps (if you need to know something specific, i can comment it separately):

1. add crossbuild toolchain support in: eng/common/cross/build-rootfs.sh
   and eng/common/cross/toolchain.cmake
2. update eng/native/configure*.cmake files for compiler options under eng/native/ directory
3. update groups with Calculate* labels in Directory.Build.props file at the root of this repo
4. for mono, update src/mono/mono.proj, src/mono/CMakeLists.txt and src/mono/Directory.Build.props files

Then run eng/common/cross/build-rootfs haiku x64 to build the rootfs enviornment and ROOTFS_DIR=$(pwd)/.tools/x64 ./build.sh -cross -arch x64 -os haiku to get started with code-only changes. From time to time, you may need to update local configurations of projects being ported, but the aforementioned central configuration take care of most of the wiring.

Later on if you want to make a persistent environment, you can get a docker tag from https://github.com/dotnet/dotnet-buildtools-prereqs-docker, with rootfs at a fixed location: /crossrootfs/x64. We did this step for illumos/SmartOS very early to make development environment stateless and build recipe sharable with other community members.

[jessicah]

Thanks @am11, is mono+libs the right target to start with? Also, what's the difference between mono in this repo, and https://github.com/mono/mono?

[am11]

is mono+libs the right target to start with?

Yes, imo, after the common configurations are done, focusing first on mono and then libraries would be the fastest way to get .NET 6 working on Haiku. Going by git grep -i haiku, you can already tell there is some related code from the initial mono port in dotnet/runtime repo.

Later you can look into corehost (dontet(1)) to make the build binaries usable with .NET SDK etc. It would also make it much easier to then port coreclr runtime.

what's the difference between mono in this repo, and https://github.com/mono/mono?

mono/mono (OSS) aims to be compatible with .NET Framework 4.7 (closed source).
Mono subset (src/mono) in this repository started off as a port of same mono runtime (minus the legacy components of .NET Framework 4.7, which are not supported in .NET 5) and implements common runtime interface as src/coreclr. The initial focus was to support various targets including, but not limited to, Xamrian, Mobile and WebAssembly that coreclr does not support today.

The core .NET libraries in this repo are tested against both (coreclr and mono) runtime flavors. The goal is to make both runtimes drop-in replacements of each other, and they can (and do) overlap when it comes to platform targets. Officially the focus for runtime/src/mono so far has been on mobile-like targets, but mono RT built from this repo runs desktop apps just fine (to do that it currently requires two manual cp steps which hopefully may no longer be needed in the future 😁).

[jessicah]

@am11 Running into a weird issue with configuration in src/libraries/Native:

https://github.com/jessicah/dotnet-runtime/blob/haiku/src/libraries/Native/Unix/System.Globalization.Native/CMakeLists.txt#L22

  CMake Error at System.Globalization.Native/CMakeLists.txt:24 (message):
    Cannot find utypes.h, try installing libicu-dev (or the appropriate package
    for your platform)

It feels like it's not searching the configured sysroot. Invoking build.sh as follows: ROOTFS_DIR=/home/jessica/build/haiku-sysroot ./build.sh mono+libs -arch x64 -os haiku -c debug -cross --ninja.

jessica@homecloud:~/build/haiku-sysroot/boot/system/develop/headers$ find -name utypes.h
./unicode/utypes.h

Not really sure what I'm doing wrong. All the checks being run in configure.cmake appear to be invoking the Haiku cross-compiler correctly. Unfortunately I can't find a log that mentions the utype.h search. It's definitely for cross-compiling, as libicu-dev is installed on host Linux.

Logs in artifacts/obj/native/net6.0-Haiku-Debug-x64/CMakeFiles: https://gist.github.com/jessicah/7f8693f773d7ddec8c51f2df15da0221

Additionally, if I comment out the search and just hard code them as succeeding, then in configure.cmake, the checks for HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS and HAVE_SET_MAX_VARIABLE both compile and pass, so the sysroot is configured correctly for compile/link, just the builtin CMake functions are not working correctly.

[am11]

Could you try adding:

+++ eng/common/cross/toolchain.cmake
--- eng/common/cross/toolchain.cmake

elseif(CMAKE_SYSTEM_NAME STREQUAL "Haiku")
    set(CMAKE_SYSROOT "${CROSS_ROOTFS}")
+    include_directories(SYSTEM ${CROSS_ROOTFS}/boot/system/develop/headers)
+    set(CMAKE_SYSTEM_PREFIX_PATH "${CROSS_ROOTFS}")
else()

to see if it gives clean result. I remember having similar issue with ICU on illumos, and tweaking toolchain.cmake helped. Your observation is spot on, the flags and definitions used by cmake introspection are different than those used for the actual compilation. IIRC, that include_directories sets it for both.

[NattyNarwhal]

I did the PAL port and (attempt at) Mono runtime stuff in mono/mono; ping me if you need me.

[jessicah]

@am11 no luck, unfortunately :-/