- GDB/LLDB support
Using the host’s GDB (Linux) on HyClone-emulated Haiku apps, or use gdb on HyClone? The latter is quite impossible as GDB is also broken on Haiku.
Is this even possible?
What I meant was HyClone-emulated Haiku apps, which are nothing but Linux processes.
Debugging these apps work, but the experience is not so good because Linux GDB does not know of symbols of Haiku binaries loaded by HyClone.
This sounds handy!
I’ve successfully built hyclone under Debian testing amd64 using the Ubuntu instructions in the readme but I’ve not tested it yet.
X512:
Should it be possible to build this under Debian on the VF2 and use it to build Haiku rv64 packages?
Wouldn’t be better to just use Haiku and build the packages with haikuports?, i mean wouldn’t there be a performance hit using this emulation?
If my x86-64 Haiku vs (Ubuntu) Linux benchmarks from last year are still valid, Linux is approx twice as fast as the Haiku (NewOS) kernel at many CPU intensive tasks like building software and compressing files etc, at least that was the case on the CPU I used for the comparison.
Should it be possible to build this under Debian on the VF2 and use it to build Haiku rv64 packages?
HyClone currently only supports x86_64. It currently has:
- Some x86_64-specific
asmblocks here and there (quite few but they exist). - Raw Linux x86_64 syscall numbers (the
__NR_* constants). - x86_64-specific Haiku constants.
HyClone was designed to be portable so it should not be too much work to port it to another architecture. However, on my TODO list are only x86 (32-bit) and probably arm64 if I can acquire a arm64 laptop after GSoC ends.
Wouldn’t be better to just use Haiku and build the packages with haikuports?, i mean wouldn’t there be a performance hit using this emulation?
There would be quite a huge hit. HyClone in its early stages did not focus on performance and its VFS-related syscalls are very slow. Building packages (a task that uses a lot of these syscalls) on HyClone is not as fast as building on Haiku.
I currently have some ideas to do (yet another) rewrite on the VFS layer to use FUSE instead of emulating my own, but I don’t have any plans to realize that at least in the next few months.
1 Like
It would be better to run regular Haiku for building packages on VisionFive 2. The benefits of using HyClone for building software are using various shared server and continuous integration infrastructure. If hardware is locally available, it should be no problem to run regular Haiku on it.
6 Likes
Is it not possible to use qemu or another RV emulator to build Haiku RV packages on amd64?
Which is the best out of qemu and this
Maybe that can’t be used to run Haiku?
Would a 32 core Xeon running qemu not be able to build Haiku packages faster than a VF2 running Haiku?
I find this really faszinating, wanted to try, i am just missing something in the setup to compile haiku on linux. Can someone give me a hint, how to set up so that the compile and libs from buildtools is used instead of the system one, also how to set up the includes.
At the jam Step i get:
In file included from …/headers/build/os/BeBuild.h:5,
from …/headers/build/…/os/support/SupportDefs.h:12,
from …/headers/build/os/support/SupportDefs.h:2,
from …/headers/build/…/os/kernel/OS.h:14,
from …/headers/build/os/kernel/OS.h:9,
from …/src/build/libroot/atomic.cpp:5:
…/headers/build/…/os/BeBuild.h:59:9: error: #error Unsupported compiler!
59 | # error Unsupported compiler!
| ^~~~~
Which compiler are you using?
gcc --version might help.
the one on my system is 13.2:
$ /usr/bin/gcc --version
gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
i added the buildtool path to my path so it its 11.3
export PATH=/home/ubu/src/haiku/generated.x86_64/cross-tools-x86_64/bin/:bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
$ gcc --version
gcc (GCC) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
but the i get:
~/src/haiku/generated.x86_64$ time jam -q -j3 @nightly-anyboot
Starting build of type regular …
Building Haiku Nightly
Asked for bios_ia32 target boot platform
Unknown path to handle adding to image
Asked for pxe_ia32 target boot platform
Unknown path to handle adding to image
…patience…
…patience…
…patience…
…patience…
…patience…
…patience…
…patience…
…patience…
…patience…
…patience…
…patience…
…found 106370 target(s)…
…updating 16350 target(s)…
C++ objects/linux/x86_64/release/build/libroot/atomic.o
C++ objects/linux/x86_64/release/build/libroot/byteorder.o
C++ objects/linux/x86_64/release/build/libroot/find_directory.o
In file included from ./…/headers/build/BeOSBuildCompatibility.h:21,
from :
…/headers/build/os/support/Errors.h:9:10: fatal error: errno.h: No such file or directory
9 | #include <errno.h> /* build-specific overrides errno /
| ^~~~~~~~~
compilation terminated.
In file included from ./…/headers/build/BeOSBuildCompatibility.h:21,
from :
…/headers/build/os/support/Errors.h:9:10: fatal error: errno.h: No such file or directory
9 | #include <errno.h> / build-specific overrides errno /
| ^~~~~~~~~
In file included from ./…/headers/build/BeOSBuildCompatibility.h:21,
from :
…/headers/build/os/support/Errors.h:9:10: fatal error: errno.h: No such file or directory
9 | #include <errno.h> / build-specific overrides errno */
| ^~~~~~~~~
compilation terminated.
compilation terminated.
I doubt that you should do this. When cross-compiling Haiku on Linux, the build system expects the gcc on $PATH to be a system native (Linux) compiler. The one from buildtools, however, is a cross-compiler for Haiku.
I once did have issues when building with 13.x. However, support for GCC 13 should have been recently added:
#if __GNUC__ == 2
# define B_HAIKU_ABI B_HAIKU_ABI_GCC_2_HAIKU
#elif (__GNUC__ >= 4 && __GNUC__ <= 13) || defined(__TINYC__)
# define B_HAIKU_ABI B_HAIKU_ABI_GCC_4
#else
# error Unsupported compiler!
#endif
Can you create a simple C file on Linux, do a printf("%i", __GNUC__);, and see what the result is?
feat: Initial arm64 support · trungnt2910/hyclone@b759b73 (github.com)
Kinda nice to see hyclone successfully built for arm64 - it was (although a bit carelessly) designed to be easily portable. Generally, the current published instructions should work.
Now it’s just the server and some packages. We can’t get into a shell on $HPREFIX yet, not even a “Hello World”, since there are still some critical stubs in runtime_loader. HyClone is a “clone” after all - it can’t get far ahead of the official arm64 Haiku.
Also, for the latest news and quick support on HyClone, please join our Discord server!
Or, if you prefer Matrix, you can join it here.
9 Likes
Please do not use Discord because some people such as me can’t access it. I was banned immediately after registration and feedback did not work. Matrix is a free better alternative that is not under control of some corporation.
4 Likes
Probably because there is literally “danger” in your email 
If there is enough interest and a free solution I might set up a Matrix room with a Discord bridge.
1 Like
Wow how interesting.!!!
Very cool, this will be as Cosmoe should be :3 very cool.
1 Like