Can't build as static OR shared in Haiku (OS) about cpu_features HOT 8 OPEN

@victroniko, according to the haiku cli documentation and os discussion, we can install them to ~/config/non-packaged/bin/ and this folder is user writable.

refs:
https://www.haiku-os.org/docs/userguide/en/applications/cli-apps.html
https://www.haiku-os.org/docs/userguide/en/filesystem-layout.html
https://discuss.haiku-os.org/t/how-do-i-make-a-libary-for-haiku-os/7075/4

Added install path c8e5e09

if(CMAKE_SYSTEM_NAME MATCHES "Haiku")
  set(CMAKE_INSTALL_LIBDIR ~/config/non-packaged/lib)
  set(CMAKE_INSTALL_BINDIR ~/config/non-packaged/bin)
  set(CMAKE_INSTALL_INCLUDEDIR ~/config/non-packaged/include)
endif()

cc: @Mizux

from cpu_features.

@victroniko, actually we don't have any architecture support for Haiku OS., see https://github.com/google/cpu_features#whats-supported. Since for older processors we have to get the processor information from the OS, that's why you get errors like undefined reference to DetectFeaturesFromOs and OverrideOsPreserves...

I added test commit 7badfd0 and all works fine:

tested on Haiku x86 32 bit via VirtualBox

probably for old processors we can get info via sysinfo:

also, in CMakeLists CMAKE_SYSTEM_PROCESSOR MATCHES it worth to add detection "x86" case:

cc: @gchatelet, @Mizux

from cpu_features.

Like for FreeBSD ci we could use a Vagrant box to perform a build:
see: https://app.vagrantup.com/haiku-os/boxes/r1beta4-x86_64
And like for FreeBSD, the CI will be fragile with the "too many request" hitting us...

note: At least we could have the Vagrant file and we could run it from time to time as best/community effort support...
ref:

from cpu_features.

Thank you for looking into this. Yes I know Haiku isn't supported... yet :)

The x86 variant is mantained mainly for binary compatibility with old BeOS 5.x, so things there are less than ideal for modern code. I was building on Haiku x86_64 (sorry I should've absolutely mentioned that!), as I believe it's the most sensible choice re: future support, codebase etc.

I tried anyway to build the test commit on x86_64, and it went further - list_cpu_features now compiles fine. But as expected, final linking fails with a bunch of x86-specific (?) undefined refs.

...

Below is a full build log from haikuporter (Haiku's tool for building packages, similar to Gentoo portage).

cpu_features-haikux64_buildlog_static.txt

from cpu_features.

@victroniko, yes, it fails because I added test commit just to check list_cpu_features without testing.
You can run list_cpu_features with the following commands:

cmake -S. -Bcmake-build-release -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build cmake-build-release --config Release
./cmake-build-release/list_cpu_features

About x86, no matter what architecture x86 or x86_64 is the same code in cpu_features. I didn't use BeOS compatibility using gcc 2.95 (need to change code to support the compiler), I used the setarch x86 command which allows you to use the latest version of gcc.

I added haiku_x86 impl file to tests and disabled OS specific tests (484a951) and it works

from cpu_features.

I can confirm it now builds (as stand-alone) correctly on Haiku x86_64. Still requires a bit more massaging to install succesfully. This is what happens if we follow install instructions as-is:

...
Install the project...
/boot/system/bin/cmake -P cmake_install.cmake
-- Install configuration: "RelWithDebInfo"
-- Installing: /boot/system/lib/libcpu_features.a
CMake Error at cmake_install.cmake:41 (file):
file INSTALL cannot copy file
"/sources/cpu_features-484a95133ca6493d80cf76782c9d15de9e1aa0d2/build/libcpu_features.a"
to "/boot/system/lib/libcpu_features.a": Read-only file system.
Makefile:109: recipe for target 'install' failed

This doesn't work because Haiku system-dirs are read only: installed packages are mounted on boot then "overlayed" on top of FS. So at install step we have to use a path-abstraction variable along with DESTDIR=, in this way cpu_features builds to 100%. But it seems it wants to install to absolute paths on /boot - there is NO abstraction for that, only for libs bin devel docs... etc.

(edit. There is $installDestDir which seems usable, but it's description says it's for other things - I've tested it and certainly, it does not change the outcome with cmake above.)

To make a crude example, this is the resulting package built with DESTDIR=$libsDir (/boot/system/lib), and the final path where things end:

As can be seen everything after $libsDir is hardcoded to /boot. With DESTDIR=$binDir things end in /boot/system/bin/boot/*, and so on. Anyway it does install, and list_cpu_features can be ran by manually cd'ing to resulting path. So it seems this is the last thing before a fully working standalone build.

Here is an example for working with Haiku's path-abstractions in C/C++, hope this helps.

Now I'm off to test if it builds as submodule of VOLK...

from cpu_features.

@gchatelet, what do you think, can we try to add support Haiku OS?

from cpu_features.

I was about to reply. It would be nice to support Haiku OS but only if we can have a CI machine. @Mizux ?

from cpu_features.