Missing some information on building Haiku

Hi. I’m trying to build the ARM version of Haiku from the nightlies, mostly just because I can. Or rather should be able to.
There seem to be some missing steps in the instructions on how to do so.

I feel there should be at least a link to this page https://www.haiku-os.org/guides/building/jam/ on building and installing Jam. In my case I opted to install it in $HOME/bin.

I should say I’m building using Debian 9 arm64.

Following this page gets me most of the way: https://www.haiku-os.org/guides/building/compiling-arm/
However there seems to be something missing. I’m guessing it needs a “source somedir” or something in there. The toolchain seems to have built fine to run on my arm64 host. However when I run “jam -j2 -q @minimum-mmc” as instructed it fails with “Unsupported gcc host machine: aarch64-linux-gnu”. Why does this matter? I have all the “arm-unknown-haiku-” toolchain built.
If it is just a matter of setting source, may I suggest a small bash script in a convenient location to set the necessary environment variables? It’d be handy for cross-compiling applications too.

In summary; What have I done wrong or failed to do?

This is referring to your “host” toolchain, as we need to know certain things about it. It seems we don’t have a case for it, which makes sense; nobody’s ever built on an ARM64 host before!

It looks like there’s already an arm64- case. Probably we should just add an aarch64- case here. I’ll take a look.

The ARM build won’t get very far though; it currently needs to be bootstrapped again, which @pulkomandy and @kallisti5 are still fighting with binutils over…

2 Likes

Thanks for the tip. I added aarch64 and tried building.

...failed C++ objects/linux/release/build/libroot/atomic.o ...
Archive objects/linux/release/build/libroot/libroot_build_function_remapper.a 
ar: creating objects/linux/release/build/libroot/libroot_build_function_remapper.a
Ranlib objects/linux/release/build/libroot/libroot_build_function_remapper.a 

BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 6 target(s)...
...updated 11 target(s)...

At least it appears that the aarch64 toolchain was functioning as it should after addition. Just thought I’d include where it broke in case it’s any use to anyone.

This doesn’t show what the actual error is, only where it occured. Please include the “error:” message from GCC also, that will show where the actual problem is.

Sure. Just quickly…

../src/tools/fs_shell/vfs.cpp: In function ‘fssh_status_t FSShell::common_unlock_node(int, bool)’:
../src/tools/fs_shell/vfs.cpp:3733:44: error: cast from ‘FSShell::file_descriptor*’ to ‘int32_t {aka int}’ loses precision [-fpermissive]
    0, (fssh_addr_t)descriptor) != (int32_t)descriptor)

While I’m here, I think an entry for aarch64 needs to be added to haiku/headers/config/HaikuConfig.h

Yes, it seems that some 64-bit flags weren’t set properly. I think I see what needs to be fixed.

2 Likes

If it gets changed in the tree, I will try it if I know about it. I only have ARM devices currently so there isn’t much other reason for me to pull changes.

Happened in hrev52961

Indeed, but that doesn’t explain all the failures I think. @ImmortanJoe, I’ll need a full build log in order to properly determine what’s going on.

I have to set the hardware back up. Hopefully a little later. For now I have the results of an attempted build on my Orange Pi Zero fileserver (armv7)
https://pastebin.com/raw/nhCHcfsD stdout

https://pastebin.com/raw/bjgYVTd4 stderr

Something odd happened to my system and I had to do some work on it. Got it all happening again. Here’s aarch64 stdout and stderr
https://pastebin.com/raw/1ANdq4T5 stdout
https://pastebin.com/raw/awe6FgJA stderr

Yeah, that’s more like it. GCC doesn’t define __arm64__, only __aarch64__. Probably if you add it to your BuildConfig's HOST_CCFLAGS manually, it should help.

Interesting thing. In BuildConfig there’s a HAIKU_CCFLAGS but no HOST_CCFLAGS

I’m feeling kind of stupid here. If I add HOST_CCFLAGS, what exactly do I add to it?

Looks like the proper name is just CCFLAGS, so try that.

Note that the ARM image can’t be built at present; it needs to be re-bootstrapped, though.

That’s fine. I just want to see how far it gets.