core::result::Result<(), vaultwarden::error::Error>, ()> ()
>
> ```
---
### Author:  [@BlackDex](https://vaultwarden.discourse.group/u/BlackDex)
#### Post date: [July 13, 2023, 9:28pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/6 "2023-07-13T21:28:37Z")
Looks like it crashes during the creation of the rsa pem generation.
Either openssl has some issues in some way. Or something else breaks.
You could try to use the `vendored_openssl` feature and see if that helps.
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 13, 2023, 9:32pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/7 "2023-07-13T21:32:59Z")
This is the code that causes the null pointer call:
```rs
pub fn init() {
use std::ptr;
#[cfg(not(ossl111b))]
let init_options = OPENSSL_INIT_LOAD_SSL_STRINGS;
#[cfg(ossl111b)]
let init_options = OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_NO_ATEXIT;
INIT.call_once(|| unsafe {
OPENSSL_init_ssl(init_options, ptr::null_mut());
})
}
```
I attempted to rebuild the binary with the `vendored_openssl` flag, and the build script fails because it can’t find openssl. It seems that it either can’t find my openssl install or I am missing a package.
---
### Author:  [@BlackDex](https://vaultwarden.discourse.group/u/BlackDex)
#### Post date: [July 13, 2023, 9:54pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/8 "2023-07-13T21:54:08Z")
Strange, as vendored should build it it self.
Do you have libssl3 installed?
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 13, 2023, 9:59pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/9 "2023-07-13T21:59:50Z")
I found the issue. I did install gcc etc, but make was missing. The error message it gave me was a bit misleading. Vaultwarden starts without any issues when run with vendored openssl, I would still like to figure out why it cannot link to it though.
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 13, 2023, 10:16pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/10 "2023-07-13T22:16:01Z")
I was able to create a minimal project to reproduce this issue without bitwarden:
```rs
use openssl_sys::init;
fn main() {
println!("calling init");
init();
println!("done");
}
```
I will create an issue at `openssl-sys` as this is not an issue with Vaultwarden.
Should I close this topic @BlackDex?
---
### Author:  [@BlackDex](https://vaultwarden.discourse.group/u/BlackDex)
#### Post date: [July 13, 2023, 10:19pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/11 "2023-07-13T22:19:39Z")
Strange that it works with vendored and not native
Which version of Alpine are you using?
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 13, 2023, 10:20pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/12 "2023-07-13T22:20:26Z")
I found this older issue which found out that apparently ~~Alpine~~ Rust is to blame for a broken openssl build:
>
>
> My environment:
> \`\`\`
> + rustup --version
> rustup 1.23.1 (2020-11-30)
> ...
> cargo… 1.50.0 (f04e7fab7 2021-02-04)
> \`\`\`
> The output from the command when running in a workspace with ~15 crates:
> \`\`\`
> $ rustup show
> Default host: x86\_64-unknown-linux-musl
> rustup home: /usr/local/rustup
> installed toolchains
> \--------------------
> nightly-x86\_64-unknown-linux-musl
> 1.50.0-x86\_64-unknown-linux-musl (default)
> active toolchain
> \----------------
> 1.50.0-x86\_64-unknown-linux-musl (default)
> rustc 1.50.0 (cb75ad5db 2021-02-10)
>
> $ cargo +nightly udeps --release --all-targets
> /bin/bash: line 147: 26 Segmentation fault (core dumped) cargo +nightly udeps --release --all-targets
> \`\`\`
> Any advice on how to resolve this issue? Thanks.
> The system-installed copy of OpenSSL dynamically links to the system MUSL, but Rust will by default statically link to a bundled MUSL, and that causes things to break when calling into OpenSSL.
> [@BlackDex](#):
>
> Which version of Alpine are you using?
Alpine 3.18
---
### Author:  [@BlackDex](https://vaultwarden.discourse.group/u/BlackDex)
#### Post date: [July 13, 2023, 10:34pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/13 "2023-07-13T22:34:36Z")
Well, that is a very old rust version, doubt it still is an issue
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 13, 2023, 10:36pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/14 "2023-07-13T22:36:14Z")
Apparently they changed it to link dynamically in the meantime:
`https://github.com/rust-lang/compiler-team/issues/422` (“An error occurred: Sorry you cannot post a link to that host.”)
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 13, 2023, 11:52pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/15 "2023-07-13T23:52:48Z")
Progress update on locating the issue: It’s a linking problem of the Rust compiler on musl:
`https://github.com/rust-lang/rust/issues/82193`
I now got the same issue with postgresql, as it calls null instead of calling the linked library function. Also I don’t think this list should be empty:
```txt
(gdb) info sharedlibrary
No shared libraries loaded at this time.
```
Good thing is that the “workaround” mentioned in the issue does work for me:
```txt
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7f78070 0x00007ffff7fc3357 Yes (*) /lib/ld-musl-x86_64.so.1
0x00007ffff7f17ff0 0x00007ffff7f37b6f Yes (*) /usr/lib/libpq.so.5
0x00007ffff7ef5330 0x00007ffff7f0a835 Yes (*) /usr/lib/libgcc_s.so.1
0x00007ffff7e7eeb0 0x00007ffff7ec6b30 Yes (*) /lib/libssl.so.3
0x00007ffff7aa3000 0x00007ffff7d3e192 Yes (*) /lib/libcrypto.so.3
```
I created the file `.cargo/config.toml` with the following content:
```toml
[target."x86_64-unknown-linux-musl"]
rustflags = ["-C", "target-feature=-crt-static"]
```
I can now compile using `cargo build --features postgresql`.
---
### Author:  [@Colin](https://vaultwarden.discourse.group/u/Colin)
#### Post date: [July 14, 2023, 1:55pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/16 "2023-07-14T13:55:01Z")
I asked on the Rust Discord and was told that this is a known compiler bug. Alpine has their own patched version of the Rust toolchain available as packages. When I compiled with the patched compiler, it worked without any issues.
---
### Author:  [@BlackDex](https://vaultwarden.discourse.group/u/BlackDex)
#### Post date: [July 14, 2023, 2:02pm UTC](https://vaultwarden.discourse.group/t/resolved-building-musl-c-version-segmentation-fault/2783/17 "2023-07-14T14:02:22Z")
Ah nice.
I actually never build using Alpine it self with the most recent versions.
I build my own gcc musl build tools and use those to build a MUSL version of Vaultwarden to be used with Alpine base images.
But, i statically build all the libraries and after that Vaultwarden.
Also, a small performance note, you might want to enable the `enable_mimalloc` feature which uses a different Memory Allocator then the default MUSL, which has some known performance issues.