Haiku: add platform support #55803
Comments
|
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. |
dotnet-issue-labeler
bot
added
the
untriaged
|
What are benefits of having Haiku as an os target vs other os'es? |
|
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):
Then run 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: |
ghost
added this to Needs triage
in 
|
Thanks @am11, is |
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 Later you can look into corehost (
mono/mono (OSS) aims to be compatible with .NET Framework 4.7 (closed source). 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 |
Tracking in dotnet#55803.
|
@am11 Running into a weird issue with configuration in It feels like it's not searching the configured sysroot. Invoking Not really sure what I'm doing wrong. All the checks being run in Logs in Additionally, if I comment out the search and just hard code them as succeeding, then in |
|
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. |
|
I did the PAL port and (attempt at) Mono runtime stuff in mono/mono; ping me if you need me. |
|
@am11 no luck, unfortunately :-/ |
|
I think it is ok to continue with a workaround at least for now. :)
best place to do this hardcoding is
|
|
Hacked my way further, but running into an issue with |
|
@am11 With jessicah@10e4e8b it "finishes", but I'm not sure what I have :p It seems like the mono build is targeted for Linux, although the .so files not related to mono are linked against the Haiku libraries. I'm guessing mono isn't configured to build for Haiku, and probably some other parts are like this too :-/ I'll have a deeper look into |
|
For mono, it would require a patch like a47b8dc (it used to be autoconf based, now mono build in this repo has been moved to cmake).
usually i run the configure-only step natively on platform (like OpenIndiana for illumos) to collect all the expected configure values then run the same with cross toolchain on linux, the diff is what goes in the tryrun.cmake (minus a things which are optional, but it doesn't hurt to have the entire diff in). |
|
A lot of that patch looks like fixes for building Illumos on Illumos, as most of these are Anyway, I've just noticed this in the build output (the That looks like I'm missing something crucial, surely this should be compiling for the target, not the host? |
Yes, haiku would need a "similar" patch, so it gets CMAKE_SYSTEM_NAME=Haiku. Also, when rebuilding after making changes, I delete artifacts directory so cmake runs the configure again.
e.g. equivalent of Line 236 in a47b8dc |
|
Ah right, I forgot that happens, had been running |
|
Admittedly,
In other words, when mono (which was and still is primarily autoconfig-like) is talking about host of cross-compiler, it means target by normal logic. Therefore, I just follow the nearby logic. :) illumos and FreeBSD are the closest matches to Haiku, as both of them cross compile on amd64 for amd64. |
|
Ah okay. Well, it looks like it may have built the cross mono stuff. Log: https://gist.github.com/jessicah/647f1e8e033c96eb2a47ed3f526e47dd I guess I can try copying some stuff over to a Haiku install, and seeing what happens. What will be the next steps, assuming I can get something to run on Haiku? |
|
Okay, copied |
|
That was fast. Great progress! It took me way longer to get this far. 🤣 On Linux box, where you have cross compiled, you can run: then edit: Copy mypublishdir to Haiku system and run It may emit a huge diagnostics and fail, but that's not the product we are interested in. We want A few notes about the setup:
Next step would be to port src/native/corehost, i.e. The method I followed to test mono on amd64 was to copy |
|
Hmm, running
Seems like it doesn't know where to look for the dlls. Tried setting MONO_PATH to various values, but no dice. I'll look into using the |
|
Well, making heaps more progress on coreclr/corehost, but now the c++ compiler has decided it doesn't know what Log: https://gist.github.com/jessicah/b7f48ab99909f4aaf2a8e11579a5c3b3 |
|
Error is coming from system header. Looks like string.h is missing or some macro definition in cmake which controls including string.h in system headers. I tried build-rootfs from haiku branch, but it is failing with: does haiku/configure require some patch to support --sysroot option? |
|
@waddlesplash you can disable the W^X by default on Haiku, actually, we do that for Rosetta x64 too - I've incorrectly stated above that we use double mapping even with Rosetta. For Rosetta, it didn't work properly as once rosetta jitted a block of code, it wasn't able to see that the code has changed via the other mapping, so any modifications to code pages that were already jitted by rosetta were never executed. |
|
Haiku now supports creating shm files on memory as well as mapping them, so why should we disable this? The real problem here is that Haiku does not provide a way to cleanly reserve and commit memory in a way similar to the Win32 API. Various features of the CoreCLR (not just the doublemapper, but also GC among other things) tries to map a huge memory block and then commit it bit by bit using mprotect. On Haiku to be able to map these huge blocks at all, either MAP_NORESERVE need to be passed to request an overcommitting region or a private API that does not map memory but only reserves addresses (reserve_address_range) has to be used instead. But after that there is no way to cleanly commit the memory areas (clear the overcommit flag or map the memory in the reserved area). A mmap with MAP_FIXED would be a tempting solution, but that destroys any existing pages in the requested range, while CoreCLR seems to rely on the Windows behavior of MEM_COMMIT ignoring existing pages. |
In the end it was indeed a double free, but it was not the code that I initially pointed. The usage of a lot of inline functions and macros made debugging a lot more complicated. This is not Haiku-specific and can possibly be triggered on any platform with a stack size small enough, so I have opened a separate pull request. |
|
Got this very weird exception message whenever I try to obtain
|
|
Latest weird error, this time encountered when running |
|
Previous issue resolved, some bug related to Haiku memory allocation is to blame. Now, I am running into this with
It seems like .NET uses epoll/kqueue to handle IO, but Haiku does not provide such an API yet. Is there a way to emulate this using |
|
Created a label, but only this issue needs it right now 😄 |
|
From #90695:
Does this mean that something happened in .NET 8 that disallows any further RID addition? Can Haiku not get its own RID? |
|
Yup, dotnet/designs#260. Now the target RID is added in corehost artifacts at the build-time. |
Can you please point out where in the codebase this is done? |
From what I understand from that issue and related materials:
So, what will happen to non-Linux UNIXes like FreeBSD and illumos? What will happen to Haiku, which is a unique OS different from the average UNIX as much as FreeBSD is different from Linux? Since |
corehost will get
SDK does not stop us for introducing new platforms in runtime repo. corehost always adds the RID of build-target, so that will continue to work after the recent breaking changes. There is even a CI with |
|
So, this means that when an SDK runs on a This would still, however, prevent cross-compilation from an SDK running on a |
|
There are two scenarios:
You can port .NET runtime and runtime libraries and continue to cross-build runtime packages on linux-x64, without caring about the SDK. Once runtime packages are built, you can then add Haiku platform spec in the dotnet/sdk and dotnet/installer (a few places in the SDK having the platform list, mainly for stuff like validation error messages). [1] NativeAOT application model is an exception, which requires cross-toolchain (e.g. gcc for target haiku-x64, or clang which is usually cross-target), but not all platforms support NativeAOT yet (it is currently supported by |
Is there any hope in https://github.com/dotnet/dotnet? Currently, I know that it only supports Linux and may assume various Linux-specific environment details, but it is said that the support will be extended to OSX and Windows in .NET 9. With a certain level of cross-platformness, should it be easier to port this repo to another platform and build .NET there without relying on an existing .NET environment?
I am already doing that That said, it is not sufficient to build the whole .NET runtime from source, because it seems to expect more to be available for Haiku: |
|
Impressive progress, @trungnt2910! In trungnt2910/dotnet-sdk@79010f6, you could also search with In general, code-wise, you may want to bring this port to the same plan as FreeBSD and then for the missing infrastructure parts, we can follow the footsteps of @Thefrank et al. dotnet/source-build#1139 (comment). By using the same approach they've used to make dotnet packages available in FreeBSD ports so far, it might help engineering teams to figure out which parts need to provide variation across multiple community-supported platforms (Haiku probably wouldn't need old versions by the time dotnet port is generally available which may make things relatively simpler). VMR (aka dotnet/dotnet) has a future in more platform support, but that will not exempt the initial port steps for new platforms (1. runtime, 2. SDK, 3. installer, 4. diagnostics repos etc.). |
|
In that commit, I have already ported done this and ported the SDK to Haiku. However, what is |
https://github.com/dotnet/installer#net-sdk-installers Installer repo creates the final binary tarball for each platform, signs and versions it. This is where the version compatibility between several components (which form the "dotnet" package) is resolved and the EndToEnd tests run. You can think of it as part of SDK, split for engineering reasons (and one day, may merge back to SDK repo). |
I see that there is a Is the in-tree LLVM |
There was a mistake in my comment. Correction:
Yes, src/native/external/llvm-libunwind is only tested with NativeAOT, and (AFAIK) nobody has tried it with CoreCLR build. We currently have patches which haven't been upstreamed (yet: #72655). You may try wiring it up using a cmake knob like |
|
Latest builds are failing with this error: Seems like whoever included According to the POSIX Standard, however:
|
|
wctype.h is mainly used by paltests. Try applying this patch: diff --git a/src/coreclr/pal/inc/pal.h b/src/coreclr/pal/inc/pal.h
index 70b934a8ccd..6aec0a80063 100644
--- a/src/coreclr/pal/inc/pal.h
+++ b/src/coreclr/pal/inc/pal.h
@@ -48,7 +48,6 @@ Abstract:
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
-#include <wctype.h>
#ifdef __cplusplus
extern "C++"
diff --git a/src/coreclr/pal/inc/pal_mstypes.h b/src/coreclr/pal/inc/pal_mstypes.h
index d59103002d1..102f3fe512f 100644
--- a/src/coreclr/pal/inc/pal_mstypes.h
+++ b/src/coreclr/pal/inc/pal_mstypes.h
@@ -541,6 +541,8 @@ typedef int SSIZE_T;
static_assert(sizeof(SIZE_T) == sizeof(void*), "SIZE_T should be pointer sized");
static_assert(sizeof(SSIZE_T) == sizeof(void*), "SSIZE_T should be pointer sized");
+char16_t __cdecl PAL_ToLowerInvariant(char16_t);
+
#ifndef SIZE_T_MAX
#define SIZE_T_MAX ULONG_PTR_MAX
#endif // SIZE_T_MAX
diff --git a/src/coreclr/pal/src/cruntime/wchar.cpp b/src/coreclr/pal/src/cruntime/wchar.cpp
index 88340538ebc..9f3175ec96f 100644
--- a/src/coreclr/pal/src/cruntime/wchar.cpp
+++ b/src/coreclr/pal/src/cruntime/wchar.cpp
@@ -24,12 +24,13 @@ Abstract:
#include "config.h"
#endif
-#include <wctype.h>
#include <errno.h>
#include <algorithm>
SET_DEFAULT_DEBUG_CHANNEL(CRT);
+#define iswspace(c) (c==0x09 || c==0x0A || c==0x0B || c==0x0C || c==0x0D || c==0x20)
+
/*--
Function:
_wtoi
diff --git a/src/coreclr/pal/src/safecrt/wcslwr_s.cpp b/src/coreclr/pal/src/safecrt/wcslwr_s.cpp
index 184776f21ee..9c04ed66a3c 100644
--- a/src/coreclr/pal/src/safecrt/wcslwr_s.cpp
+++ b/src/coreclr/pal/src/safecrt/wcslwr_s.cpp
@@ -11,7 +11,6 @@
*
*******************************************************************************/
-#include <wctype.h>
#include <string.h>
#include <errno.h>
#include <limits.h>
@@ -30,7 +29,7 @@ DLLEXPORT errno_t __cdecl _wcslwr_s(char16_t *string, size_t sz)
for (int i = 0; string[i] != 0; i++)
{
- string[i] = (char16_t)towlower(string[i]);
+ string[i] = (char16_t)PAL_ToLowerInvariant(string[i]);
}
_FILL_STRING(string, sz, length + 1);
diff --git a/src/coreclr/pal/tests/palsuite/common/palsuite.h b/src/coreclr/pal/tests/palsuite/common/palsuite.h
index 9494daed71b..d92aa8b8ed0 100644
--- a/src/coreclr/pal/tests/palsuite/common/palsuite.h
+++ b/src/coreclr/pal/tests/palsuite/common/palsuite.h
@@ -26,6 +26,7 @@ typedef unsigned short char16_t;
#include <minipal/utils.h>
#include <minipal/types.h>
#include <errno.h>
+#include <wctype.h>
#define PALTEST(testfunc, testname) \
int __cdecl testfunc(int argc, char* argv[]); \ |
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 insrc/libraries/Common/src/Interop`.Thus far it hasn't required a functioning cross-compiler yet, have only just started.
The text was updated successfully, but these errors were encountered: