Hello Stephan,

"Viking667" in the Haiku IRC channel forwarded a link to this post and asked if someone with Haiku knowledge could reply. So here is a reply :)

rpath: What would the rpath be set to? It conventionally defaults to $prefix/lib, but the default prefix doesn't match Haiku's filesystem layout.

It doesn't matter very much. The runtime ELF loader always falls back to the system/environment library paths if the required libraries were not found in rpath/runpath (see source code). So this is only relevant if there will be dependent libraries which will deliberately not be placed in the system search paths, nor in some custom LIBRARY_PATH (the Haiku equivalent of LD_LIBRARY_PATH), nor in a lib subdirectory of wherever the/a main executable is found (as this is part of the default search paths: that's what %A/lib means in the default LIBRARY_PATH.)

Should this flag be set to some default on Haiku and, if so, what should the default soname be? (i.e. what has it historically been in Haiku sqlite packages?)

It's just been whatever the sqlite build system set it to before (so libsqlite.so.0 apparently.) You can see the HaikuPorts recipe for SQLite which is used to build binary packages for Haiku, it (and the accompanying small .patchset file) don't change anything in that department.

default prefix doesn't match Haiku's filesystem layout.

(Answering most of the filesystem-layout-related questions at once here...)

The default installation paths in ./configure matter only in case someone wants to build and install SQLite system-wide outside the Haiku package manager and does not want to have to specify where it goes.

You can see in the HaikuPorts recipe that the SQLite configure script is invoked by a macro called runConfigure; this passes arguments specifying all the installation paths directly (prefix, bindir, libdir, etc.) There are multiple reasons for this, but one of them is that the directories change based on the name and version of the "recipe" being built. During build time, these directories will be readable and writable, but in all installed environments they will only ever be read-only (as they'll live inside block-compressed filesystem images and made visible in the VFS at boot or install time by packagefs.)

(If you want to know more, there's some good general background on the Haiku package manager in this blog post.)

So all the default system directories like bin, lib, develop/headers, etc. are read-only and only contain files that are inside mounted packages. There is /system/non-packaged and ~/config/non-packaged/ with a parallel hierarchy that is writable and present on the regular boot filesystem, this is vaguely analogous to /usr/local or the like. So if there is any default, it should be that. But it could also make sense to just have no default at all on Haiku and make users or developers specify what they want.

If you do decide to go that route, rather than hardcoding any particular path, you can use the finddir command on Haiku. For example:

$ finddir B_SYSTEM_NONPACKAGED_HEADERS_DIRECTORY
/boot/system/non-packaged/develop/headers

There are other equivalent constants for the other directories, of course. (This CLI tool wraps a C API that provides the same information, in case that might be of any use.)

Installation:

binaries, libraries, man pages, and pkg-config files are currently handled by the HaikuPorts recipe, most just via specifying paths via runConfigure as noted above, and for pkg-config it moves that file into the correct directory (that's what fixPkgconfig does.) You can install the sqlite and sqlite_devel (and also sqlite_debuginfo) packages and see what the layout is now, I suppose, but as noted above our scripts will take care of most of this.

Anything else? Are there other platform-isms which need to be accounted for?

Possibly, but I don't know which ones in particular SQLite might care about off the top of my head...

SQLite has been running on Haiku for many, many years, and I don't recall any particular problems that arose which seemed to be misconfigurations or incompatibilities in SQLite. Overall, Haiku tries to be as POSIX compliant as reasonably possible; we have already implemented a lot of POSIX-2024 in fact. Of course the system is still in beta and there may be bugs or missing features; if there's something you find we are missing which is degrading SQLite's functionality in some way, do let us know and we'll see what we can do :)

It won't detect three different network cards on my spare computer

Hmm, that's odd. Haiku has a source compatibility layer for BSD network drivers, and as a result has most of the consumer-grade ones for both ethernet and WiFi from FreeBSD, and some from OpenBSD where those don't suffice. (This includes compatibility with many USB WiFi devices, but note that hotplug isn't supported for those, you'll have to have them plugged in before booting.) If any one of those cards is fully supported on FreeBSD but didn't come up on Haiku, that may mean a bug in Haiku. You can check the /var/log/syslog for errors; if you know the names of the equivalent BSD drivers, you can just grep for that and see if there's anything that shows up.

so it's limited to running in a VM, which is cramped and uncomfortable.

Anything that's due to configuration here -- or do you just mean that VMs themselves are cramped/uncomfortable, nothing to do with Haiku specifically?

Lastly, thanks for your time! It's great to see more project upstreams taking even a passing interest in Haiku; the more patches we can get out of our ports tree and into upstreams, the less maintenance burden for us, and the easier for others to adopt Haiku :)

-waddlesplash

"Viking667" in the Haiku IRC channel forwarded a link to this post and asked if someone with Haiku knowledge could reply. So here is a reply :)

Thank you, brickviking, for passing that on!

It [rpath] doesn't matter very much.

Great, then it falls into the category of "if it ain't broke, don't fix it" :).

It's just been whatever the sqlite build system set it to before

The "legacy" build (versions 3.47 and earlier) set it to libsqlite3.so.0. The "new" build does not set it by default but does provide a configure flag for which retains that behavior: --soname=legacy. For a discussion of that change, see src:/forumpost/9e1dd7ea6b.

SQLite has been running on Haiku for many, many years, and I don't recall any particular problems that arose which seemed to be misconfigurations or incompatibilities in SQLite.

None of the changes related to this thread affect the library code, just the build process (which was recently completely reimplemented). To the best of my knowledge there are no known Haiku-specific issues with the library, but there may be Haiku-specific issues with the build process. The GNU Autotools (which 3.47 and earlier used) took care of lots of platform-specific voodoo which we now need to handle on our own (which we prefer, actually, so that we understand what's going on and so that we have control over it). So far the Haiku build "works for me," but Haiku package maintainers may have specific needs/expectations which aren't met by the 3.48+ build process. In any case, Haiku is one of my frequently-tested platforms for build changes, along with OpenBSD, various flavors of Linux, Cygwin, and Msys2.

Hmm, that's odd. Haiku has a source compatibility layer for BSD network drivers

i've no idea whether any of the BSDs run (with networking) on that machine, either. Shrug.

Anything that's due to configuration here -- or do you just mean that VMs themselves are cramped/uncomfortable, nothing to do with Haiku specifically?

Windowed VMs are just cramped and uncomfortable in general - nothing at all Haiku-specific. It runs wonderfully in VirtualBox, it's just generally annoying to have to deal with "mouse capture" and that sort of thing in a VM. (Ideally it would run on my idle pi4, but it doesn't support ARM platforms.)

Lastly, thanks for your time! It's great to see more project upstreams taking even a passing interest in Haiku; the more patches we can get out of our ports tree and into upstreams, the less maintenance burden for us, and the easier for others to adopt Haiku :)

That's kinda my hope here. If you find ways that the build can be improved for Haiku, please post them here in the forum or email them to me (stephan at this domain).

Thank you for the feedback!

The "legacy" build (versions 3.47 and earlier) set it to libsqlite3.so.0. The "new" build does not set it by default but does provide a configure flag for which retains that behavior: --soname=legacy.

OK, good to know.

So far the Haiku build "works for me," but Haiku package maintainers may have specific needs/expectations which aren't met by the 3.48+ build process.

The only need we have in particular is for all the standard configure install path arguments (not just "prefix" but also "bindir", "libdir", "includedir", etc.) to work more or less as before. So long as they do, all should be well.

it's just generally annoying to have to deal with "mouse capture"

You can set "USB Tablet" pointing device in VirtualBox settings to avoid the need for mouse capture. (And if you primarily work inside terminals, you can just port-forward the SSH server and work through SSH instead of in Haiku directly...)

(Ideally it would run on my idle pi4, but it doesn't support ARM platforms.)

Yes, that's a common request... most of the development team is focused on other things at the moment (we all run x86 desktops/laptops, after all) and only occasionally does the ARM port see work. At present, in VMs, the ARM32 port gets close to starting the desktop, and the ARM64 port can at least mount the boot filesystem (which is quite a ways into the kernel boot process) but they stall out or crash after that. So there's a ways to go on that.

-waddlesplash

The only need we have in particular is for all the standard configure install path arguments (not just "prefix" but also "bindir", "libdir", "includedir", etc.) to work more or less as before. So long as they do, all should be well.

It supports all of them which are relevant to its own build process, but does not do anything useful with some of the more exotic ones which aren't relevant for its purposes, e.g. --sysconfdir will be accepted but the build won't do anything with it.

You can set "USB Tablet" pointing device in VirtualBox settings to avoid the need for mouse capture.

An excellent tip, thank you - that's proven very helpful this evening.

Based on input from your IRC user Viking667 (a.k.a. brickviking), we've reached a minor milestone: as of src:c4a558291175378f, the following works on Haiku with no client-side hoop-jumping:

$ ./configure && make && make install
...
$ cd ~
$ sqlite3
... (still haven't gotten copy/paste from Haiku-in-a-VirtualBox to here working, so no text-screenshot)...

It supports all of them which are relevant to its own build process

That's all we need; so that's good then.

(still haven't gotten copy/paste from Haiku-in-a-VirtualBox to here working, so no text-screenshot)

I used to have some setups with it working, years ago, but I think nobody's managed to recompile the guest additions port in some time. (These days I mostly use VMware, and the VMware shared clipboard support in Haiku works pretty reliably.)

-waddlesplash