meta: BSD support

nex commented

2025-04-21 20:04:48 +00:00

Owner

BSD support in continuwuity, carried over from conduwuit, is quite poor, requiring some manual labour to get a working binary.

This issue should be used to discuss improvements and issues regarding building for and running continuwuity on BSD platforms.

BSD support in continuwuity, carried over from conduwuit, is quite poor, requiring some manual labour to get a working binary. This issue should be used to discuss improvements and issues regarding building for and running continuwuity on BSD platforms.

nex added the

Good first issue

Meta

Meta/Packaging

labels

2025-04-21 20:04:48 +00:00

Aranjedeath commented

2025-04-21 20:07:27 +00:00

Owner

Currently, a cargo build --release results in segfault on launch with this:

<jemalloc>: Invalid conf pair: tcache_max:2097152
<jemalloc>: No getcpu support: percpu_arena:percpu
<jemalloc>: option background_thread currently supports pthread only

so perhaps making jemalloc optional somehow on non-linux platforms would be good. I don't know what the correct approach is here, though.

Currently, a cargo build --release results in segfault on launch with this: ``` <jemalloc>: Invalid conf pair: tcache_max:2097152 <jemalloc>: No getcpu support: percpu_arena:percpu <jemalloc>: option background_thread currently supports pthread only ``` so perhaps making jemalloc optional somehow on non-linux platforms would be good. I don't know what the correct approach is here, though.

Jade commented

2025-04-22 00:09:13 +00:00

Owner

Rust has the ability to set different default features and dependencies per platform in Cargo.toml, this should be a relatively simple fix for whoever gets around to it.

nex commented

2025-04-22 01:35:15 +00:00

Author

Owner

I'll get on this tomorrow, unless someone beats me to it

Esjott commented

2025-04-29 19:18:36 +00:00

Compiled it yesterday (and since rc3 I guess) under FreeBSD with

cargo build --release --timings --no-default-features --features=sentry_telemetry,gzip_compression,zstd_compression,brotli_compression,media_thumbnail,release_max_log_level,element_hacks,url_preview

Without any issues. It was suggested by someone in the conduwuit channel back then.

Compiled it yesterday (and since rc3 I guess) under FreeBSD with `cargo build --release --timings --no-default-features --features=sentry_telemetry,gzip_compression,zstd_compression,brotli_compression,media_thumbnail,release_max_log_level,element_hacks,url_preview ` Without any issues. It was suggested by someone in the conduwuit channel back then.

Aranjedeath commented

2025-04-29 21:50:02 +00:00

Owner

Yup, it was probably me, my current command is

cargo build --release --timings --no-default-features --features=gzip_compression,zstd_compression,brotli_compression,media_thumbnail,release_max_log_level,element_hacks,url_preview,blurhashing

(removes sentry, adds blur hashing feature)

Yup, it was probably me, my current command is ``` cargo build --release --timings --no-default-features --features=gzip_compression,zstd_compression,brotli_compression,media_thumbnail,release_max_log_level,element_hacks,url_preview,blurhashing ``` (removes sentry, adds blur hashing feature)

Jade commented

2025-04-30 14:40:09 +00:00

Owner

(for now sentry doesn't do anything by default, so unless you have your own endpoint setup for it there's not much point in enabling it)

SkuLD commented

2025-05-01 23:17:53 +00:00

I also had <jemalloc>: option background_thread currently supports pthread only, found this bug and was able to avoid the SEGFAULT by running continuwuation with the environment variable MALLOC_CONF set:

env MALLOC_CONF=background_thread:false ./conduwuit

works for me :)

I also had `<jemalloc>: option background_thread currently supports pthread only`, found [this bug](https://github.com/jemalloc/jemalloc/issues/2251) and was able to avoid the SEGFAULT by running continuwuation with the environment variable `MALLOC_CONF` set: env MALLOC_CONF=background_thread:false ./conduwuit works for me :)

lily commented

2025-11-15 20:57:39 +00:00

Contributor

Working on OpenBSD (VM) currently :) sofar haven't managed to compile c10y yet due to missing libraries and library static builds error-ing; earlier I managed to compile necessary clang libs (both static and shared).

To sum up what I have done sofar:

set up OpenBSD (relatively quick) and grab all the necessary packages I
git clone the upstream, as well as llvm-project to only do static build, following the bits from https://github.com/KyleMayes/clang-sys
transplant libclang.a in /usr/lib as well as libclang.so.22.0.0.git, prefix the cargo commandline used by @Aranjedeath with LLVM_DIR=/usr/lib (because clang-sys complains about not being able to find them, even though llvm-config --libdir is a thing, not to mention casually ignoring statically built clang library)

After that, I have gotten stuck on RocksDB undefined references errors sofar. I have added the files for further details :3c
Appending bindgen-static to cargo commandline didn't really change anything significant but yeah...

Note to anyone who plans to spin OpenBSD up: Make sure that your account is part of staff, and be able to manipulate ulimit, since the set ulimit for memory is genuinely small, so if you encounter out of memory issues, make sure to change that up like for example by bumping up ulimit with ulimit -d yournumhere, otherwise like building llvm-project won't work

Working on OpenBSD (VM) currently :) sofar haven't managed to compile c10y yet due to missing libraries and library static builds error-ing; earlier I managed to compile necessary clang libs (both static and shared). To sum up what I have done sofar: 1) set up OpenBSD (relatively quick) and grab all the necessary packages I 2) git clone the upstream, as well as llvm-project to only do static build, following the bits from https://github.com/KyleMayes/clang-sys 3) transplant libclang.a in /usr/lib as well as libclang.so.22.0.0.git, prefix the cargo commandline used by @Aranjedeath with `LLVM_DIR=/usr/lib` (because `clang-sys` complains about not being able to find them, even though `llvm-config --libdir` is a thing, not to mention casually ignoring statically built clang library) After that, I have gotten stuck on RocksDB undefined references errors sofar. I have added the files for further details :3c Appending bindgen-static to cargo commandline didn't really change anything significant but yeah... Note to anyone who plans to spin OpenBSD up: Make sure that your account is part of staff, and be able to manipulate ulimit, since the set ulimit for memory is genuinely small, so if you encounter out of memory issues, make sure to change that up like for example by bumping up ulimit with `ulimit -d yournumhere`, otherwise like building llvm-project won't work

openbsd-continuwuity-err0.txt

1.4 KiB

openbsd-continuwuity-err1.txt

16 KiB

lily commented

2025-11-16 13:44:49 +00:00

Contributor

heck yeah, awoOOOoOo!! I'm actually compiling continuwuity properly now that I've compiled llvm-project libs natively and copied final shared objects to /usr/lib, no undefined symbols errors sofar, and yay, it compiled with no errors!!!

.../conduwuit -h works under OpenBSD :) I'll drop text files soon along with commandline that I've used to get it working, and eventually I'll do another double-check to see whether I can exclude static libs completely as that was the biggest issue I've had sofar, even compiling rocksdb would fail so it seems like having llvm-project be compiled only might be the viable solution.

Turns out, adding bindgen-runtime to build commandline did make a difference.

heck yeah, awoOOOoOo!! I'm actually compiling continuwuity properly now that I've compiled llvm-project libs natively and copied final shared objects to /usr/lib, no undefined symbols errors sofar, and yay, it compiled with no errors!!! `.../conduwuit -h` works under OpenBSD :) I'll drop text files soon along with commandline that I've used to get it working, and eventually I'll do another double-check to see whether I can exclude static libs completely as that was the biggest issue I've had sofar, even compiling rocksdb would fail so it seems like having llvm-project be compiled only might be the viable solution. Turns out, adding `bindgen-runtime` to build commandline did make a difference.

lily commented

2025-11-16 14:01:02 +00:00

Contributor

here are things i've noted :) hopefully I'll test it soon!

openbsd-c10y-success.txt

16 KiB

openbsd-c10y-success-cargo.txt

283 B

openbsd-c10y-success-cmdline.txt

615 B

lily commented

2025-11-16 20:58:17 +00:00

Contributor

Okay so yeah, after a lot of learning and riding the pain train, I've found out the shortest and efficient path to get continuwuity working under OpenBSD :3c

essentially, a big ! when it comes to OpenBSD is that one's actual stuff to use for development are in /usr/local/*, not /usr... (where super duper serious system stuff are that are not meant to be directly handled with) I mean, basically genuinely distinct from how Linux distributions do file hierarchy, anyway.

So after lots of tinkering around to get a paw of OpenBSD, for any future contributors and testers, minimally you will need git rust llvm, I think any of the three LLVM versions you'll be choosing from for current OpenBSD (7.8 as of 16.11.2025) should work fine!

Before using cargo, make sure to export LLVM_DIR=$(llvm-config-* --libdir) and despite not knowing the analogue, LIBCLANG_PATH=/usr/local/llvm*/lib/libclang.so.0.0. Also, set ulimit -d to be much higher like mentioned above!

Since jemalloc refuses to compile with --feature full, as well as bindgen-static not working also, the current working commandline is based on one by Aranje, with timing removed and bindgen-runtime made explicit.

cargo build --release --no-default-features --features=gzip_compression,zstd_compression,brotli_compression,media_thumbnail,release_max_log_level,element_hacks,url_preview,blurhashing,bindgen-runtime

Okay so yeah, after a lot of learning and riding the pain train, I've found out the shortest and efficient path to get continuwuity working under OpenBSD :3c essentially, a big ! when it comes to OpenBSD is that one's actual stuff to use for development are in /usr/local/*, not /usr... (where super duper serious system stuff are that are not meant to be directly handled with) I mean, basically genuinely distinct from how Linux distributions do file hierarchy, anyway. So after lots of tinkering around to get a paw of OpenBSD, for any future contributors and testers, minimally you will need `git rust llvm`, I think any of the three LLVM versions you'll be choosing from for current OpenBSD (7.8 as of 16.11.2025) should work fine! Before using cargo, make sure to export `LLVM_DIR=$(llvm-config-* --libdir)` and despite not knowing the analogue, `LIBCLANG_PATH=/usr/local/llvm*/lib/libclang.so.0.0`. Also, set `ulimit -d` to be much higher like mentioned above! Since jemalloc refuses to compile with --feature full, as well as `bindgen-static` not working also, the current working commandline is based on one by Aranje, with timing removed and `bindgen-runtime` made explicit. `cargo build --release --no-default-features --features=gzip_compression,zstd_compression,brotli_compression,media_thumbnail,release_max_log_level,element_hacks,url_preview,blurhashing,bindgen-runtime`

lily commented

2025-11-16 21:04:07 +00:00

Contributor

As for how the newly compiled OpenBSD continuwuity fares, I can't say much other than it being able output help and require configuration file, haven't tested it with Complement yet either, so feel free to continue from where I left off and correct me on what I may have gotten wrong!

lapingvino commented

2025-11-18 20:42:50 +00:00

(my reference ulimit is ulimit -d 8388608 on an 8GB RAM system)

(my reference ulimit is `ulimit -d 8388608` on an 8GB RAM system)

Rows
Columns

meta: BSD support #785