How to compile a static musl binary of a Rust project with native dependencies?
I have a project with dependencies on Hyper and Diesel, and because of that, on native libraries OpenSSL and libpq. The project builds on nightly Rust because it uses compiler plugins.
My current attempt is to build on a Docker container. I have the MUSL libc and the libraries make
'd and installed with prefix /usr/local/musl
. I run cargo
with the following command: (Not sure if some of the options are redundant, I'm not too well-versed with the compiler chain, and not even sure if they end up to the linker, but I have to try, right.)
LDFLAGS="-static -L/usr/local/musl/lib"
LD_LIBRARY_PATH=/usr/local/musl/lib:$LD_LIBRARY_PATH
CFLAGS="-I/usr/local/musl/include"
PKG_CONFIG_PATH=/usr/local/musl/lib/pkgconfig
cargo build --release --target=x86_64-unknown-linux-musl
When I ldd
the resulting file, it reveals this:
$ ldd server
linux-vdso.so.1 (0x00007fffb878e000)
libpq.so.5 => /usr/local/musl/lib/libpq.so.5 (0x00007f4d730e7000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4d72e82000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4d72a85000)
libc.so => /usr/local/musl/lib/libc.so (0x00007f4d727f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d725f2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d72246000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055e2124a2000)
There's all that dynamically linked stuff, and some even with the "x86_64-linux-gnu" chain! What went wrong?
I can make statically linked, simple pure-Rust projects without problems. ldd
says that they are statically linked, and they run without problems, unlike the executable I have problems with.
When I used --verbose
with Cargo, I got the following rustc
command that actually builds the executable: http://pastebin.com/ywv0zNBK (Oops, that one had a custom outdir
and -Z print-link-args
, added by me)
Adding the print-link-args
flag, I got the following linker command: http://pastebin.com/Aw43qd7h
How do I get cargo
or rustc
to believe that I want a static binary?
rust static-linking rust-cargo musl
add a comment |
I have a project with dependencies on Hyper and Diesel, and because of that, on native libraries OpenSSL and libpq. The project builds on nightly Rust because it uses compiler plugins.
My current attempt is to build on a Docker container. I have the MUSL libc and the libraries make
'd and installed with prefix /usr/local/musl
. I run cargo
with the following command: (Not sure if some of the options are redundant, I'm not too well-versed with the compiler chain, and not even sure if they end up to the linker, but I have to try, right.)
LDFLAGS="-static -L/usr/local/musl/lib"
LD_LIBRARY_PATH=/usr/local/musl/lib:$LD_LIBRARY_PATH
CFLAGS="-I/usr/local/musl/include"
PKG_CONFIG_PATH=/usr/local/musl/lib/pkgconfig
cargo build --release --target=x86_64-unknown-linux-musl
When I ldd
the resulting file, it reveals this:
$ ldd server
linux-vdso.so.1 (0x00007fffb878e000)
libpq.so.5 => /usr/local/musl/lib/libpq.so.5 (0x00007f4d730e7000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4d72e82000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4d72a85000)
libc.so => /usr/local/musl/lib/libc.so (0x00007f4d727f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d725f2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d72246000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055e2124a2000)
There's all that dynamically linked stuff, and some even with the "x86_64-linux-gnu" chain! What went wrong?
I can make statically linked, simple pure-Rust projects without problems. ldd
says that they are statically linked, and they run without problems, unlike the executable I have problems with.
When I used --verbose
with Cargo, I got the following rustc
command that actually builds the executable: http://pastebin.com/ywv0zNBK (Oops, that one had a custom outdir
and -Z print-link-args
, added by me)
Adding the print-link-args
flag, I got the following linker command: http://pastebin.com/Aw43qd7h
How do I get cargo
or rustc
to believe that I want a static binary?
rust static-linking rust-cargo musl
I'm pretty sure the answer is: "you don't, easily". You will need to rebuild libpq and OpenSSL as static libraries (and linked to MUSL?). You then have to figure out how to change the corresponding Rust libraries to link to the static versions. I'm like 70% sure, but not completely.
– Shepmaster
Nov 19 '16 at 16:16
The thing is, I did rebuild them against MUSL, in the prefix/usr/local/musl
. And I'm trying to get the corresponding libs to link to the static versions by trying to set the environment right, but apparently I'm failing. The way you put it sounds like I'd have to modify the libraries themselves, is that what you meant?
– GolDDranks
Nov 19 '16 at 16:32
I mean, once you have compiled the MUSL versions of the C libraries (nicely done!), you will have to poke at each of the Rust bindings to figure out how to change how they link and to what. For example, openssl has environment variables.
– Shepmaster
Nov 19 '16 at 16:37
This was cross posted to Reddit.
– Shepmaster
Nov 19 '16 at 20:44
Thanks for the pointer about the environment variables! That was a crucial clue.
– GolDDranks
Nov 20 '16 at 7:27
add a comment |
I have a project with dependencies on Hyper and Diesel, and because of that, on native libraries OpenSSL and libpq. The project builds on nightly Rust because it uses compiler plugins.
My current attempt is to build on a Docker container. I have the MUSL libc and the libraries make
'd and installed with prefix /usr/local/musl
. I run cargo
with the following command: (Not sure if some of the options are redundant, I'm not too well-versed with the compiler chain, and not even sure if they end up to the linker, but I have to try, right.)
LDFLAGS="-static -L/usr/local/musl/lib"
LD_LIBRARY_PATH=/usr/local/musl/lib:$LD_LIBRARY_PATH
CFLAGS="-I/usr/local/musl/include"
PKG_CONFIG_PATH=/usr/local/musl/lib/pkgconfig
cargo build --release --target=x86_64-unknown-linux-musl
When I ldd
the resulting file, it reveals this:
$ ldd server
linux-vdso.so.1 (0x00007fffb878e000)
libpq.so.5 => /usr/local/musl/lib/libpq.so.5 (0x00007f4d730e7000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4d72e82000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4d72a85000)
libc.so => /usr/local/musl/lib/libc.so (0x00007f4d727f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d725f2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d72246000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055e2124a2000)
There's all that dynamically linked stuff, and some even with the "x86_64-linux-gnu" chain! What went wrong?
I can make statically linked, simple pure-Rust projects without problems. ldd
says that they are statically linked, and they run without problems, unlike the executable I have problems with.
When I used --verbose
with Cargo, I got the following rustc
command that actually builds the executable: http://pastebin.com/ywv0zNBK (Oops, that one had a custom outdir
and -Z print-link-args
, added by me)
Adding the print-link-args
flag, I got the following linker command: http://pastebin.com/Aw43qd7h
How do I get cargo
or rustc
to believe that I want a static binary?
rust static-linking rust-cargo musl
I have a project with dependencies on Hyper and Diesel, and because of that, on native libraries OpenSSL and libpq. The project builds on nightly Rust because it uses compiler plugins.
My current attempt is to build on a Docker container. I have the MUSL libc and the libraries make
'd and installed with prefix /usr/local/musl
. I run cargo
with the following command: (Not sure if some of the options are redundant, I'm not too well-versed with the compiler chain, and not even sure if they end up to the linker, but I have to try, right.)
LDFLAGS="-static -L/usr/local/musl/lib"
LD_LIBRARY_PATH=/usr/local/musl/lib:$LD_LIBRARY_PATH
CFLAGS="-I/usr/local/musl/include"
PKG_CONFIG_PATH=/usr/local/musl/lib/pkgconfig
cargo build --release --target=x86_64-unknown-linux-musl
When I ldd
the resulting file, it reveals this:
$ ldd server
linux-vdso.so.1 (0x00007fffb878e000)
libpq.so.5 => /usr/local/musl/lib/libpq.so.5 (0x00007f4d730e7000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f4d72e82000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4d72a85000)
libc.so => /usr/local/musl/lib/libc.so (0x00007f4d727f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d725f2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d72246000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x000055e2124a2000)
There's all that dynamically linked stuff, and some even with the "x86_64-linux-gnu" chain! What went wrong?
I can make statically linked, simple pure-Rust projects without problems. ldd
says that they are statically linked, and they run without problems, unlike the executable I have problems with.
When I used --verbose
with Cargo, I got the following rustc
command that actually builds the executable: http://pastebin.com/ywv0zNBK (Oops, that one had a custom outdir
and -Z print-link-args
, added by me)
Adding the print-link-args
flag, I got the following linker command: http://pastebin.com/Aw43qd7h
How do I get cargo
or rustc
to believe that I want a static binary?
rust static-linking rust-cargo musl
rust static-linking rust-cargo musl
edited Nov 19 '16 at 16:13
Shepmaster
156k14315457
156k14315457
asked Nov 19 '16 at 16:06
GolDDranksGolDDranks
9992920
9992920
I'm pretty sure the answer is: "you don't, easily". You will need to rebuild libpq and OpenSSL as static libraries (and linked to MUSL?). You then have to figure out how to change the corresponding Rust libraries to link to the static versions. I'm like 70% sure, but not completely.
– Shepmaster
Nov 19 '16 at 16:16
The thing is, I did rebuild them against MUSL, in the prefix/usr/local/musl
. And I'm trying to get the corresponding libs to link to the static versions by trying to set the environment right, but apparently I'm failing. The way you put it sounds like I'd have to modify the libraries themselves, is that what you meant?
– GolDDranks
Nov 19 '16 at 16:32
I mean, once you have compiled the MUSL versions of the C libraries (nicely done!), you will have to poke at each of the Rust bindings to figure out how to change how they link and to what. For example, openssl has environment variables.
– Shepmaster
Nov 19 '16 at 16:37
This was cross posted to Reddit.
– Shepmaster
Nov 19 '16 at 20:44
Thanks for the pointer about the environment variables! That was a crucial clue.
– GolDDranks
Nov 20 '16 at 7:27
add a comment |
I'm pretty sure the answer is: "you don't, easily". You will need to rebuild libpq and OpenSSL as static libraries (and linked to MUSL?). You then have to figure out how to change the corresponding Rust libraries to link to the static versions. I'm like 70% sure, but not completely.
– Shepmaster
Nov 19 '16 at 16:16
The thing is, I did rebuild them against MUSL, in the prefix/usr/local/musl
. And I'm trying to get the corresponding libs to link to the static versions by trying to set the environment right, but apparently I'm failing. The way you put it sounds like I'd have to modify the libraries themselves, is that what you meant?
– GolDDranks
Nov 19 '16 at 16:32
I mean, once you have compiled the MUSL versions of the C libraries (nicely done!), you will have to poke at each of the Rust bindings to figure out how to change how they link and to what. For example, openssl has environment variables.
– Shepmaster
Nov 19 '16 at 16:37
This was cross posted to Reddit.
– Shepmaster
Nov 19 '16 at 20:44
Thanks for the pointer about the environment variables! That was a crucial clue.
– GolDDranks
Nov 20 '16 at 7:27
I'm pretty sure the answer is: "you don't, easily". You will need to rebuild libpq and OpenSSL as static libraries (and linked to MUSL?). You then have to figure out how to change the corresponding Rust libraries to link to the static versions. I'm like 70% sure, but not completely.
– Shepmaster
Nov 19 '16 at 16:16
I'm pretty sure the answer is: "you don't, easily". You will need to rebuild libpq and OpenSSL as static libraries (and linked to MUSL?). You then have to figure out how to change the corresponding Rust libraries to link to the static versions. I'm like 70% sure, but not completely.
– Shepmaster
Nov 19 '16 at 16:16
The thing is, I did rebuild them against MUSL, in the prefix
/usr/local/musl
. And I'm trying to get the corresponding libs to link to the static versions by trying to set the environment right, but apparently I'm failing. The way you put it sounds like I'd have to modify the libraries themselves, is that what you meant?– GolDDranks
Nov 19 '16 at 16:32
The thing is, I did rebuild them against MUSL, in the prefix
/usr/local/musl
. And I'm trying to get the corresponding libs to link to the static versions by trying to set the environment right, but apparently I'm failing. The way you put it sounds like I'd have to modify the libraries themselves, is that what you meant?– GolDDranks
Nov 19 '16 at 16:32
I mean, once you have compiled the MUSL versions of the C libraries (nicely done!), you will have to poke at each of the Rust bindings to figure out how to change how they link and to what. For example, openssl has environment variables.
– Shepmaster
Nov 19 '16 at 16:37
I mean, once you have compiled the MUSL versions of the C libraries (nicely done!), you will have to poke at each of the Rust bindings to figure out how to change how they link and to what. For example, openssl has environment variables.
– Shepmaster
Nov 19 '16 at 16:37
This was cross posted to Reddit.
– Shepmaster
Nov 19 '16 at 20:44
This was cross posted to Reddit.
– Shepmaster
Nov 19 '16 at 20:44
Thanks for the pointer about the environment variables! That was a crucial clue.
– GolDDranks
Nov 20 '16 at 7:27
Thanks for the pointer about the environment variables! That was a crucial clue.
– GolDDranks
Nov 20 '16 at 7:27
add a comment |
2 Answers
2
active
oldest
votes
The problem was that for each crate providing a native dependency – say OpenSSL – there is the build.rs
build script that is in charge of communicating the build and linking options to Cargo and to rustc
. (For example: they print out something like cargo:rustc-link-lib=static=ssl
which Cargo then reads and acts accordingly.)
So, just setting the "standard" GCC environmental variables is hardly going to have any effect. You must check each and every build.rs
separately to know how to coerce that exact crate to convey cargo it's options. For OpenSSL, it's env vars like OPENSSL_DIR
, OPENSSL_STATIC
etc.
Another hurdle is that if you use compiler plugins, they might be compiled with the target triplet too (at least docker_codegen). On the other hand, they are linked dynamically during the compiling process. This mean that not only must static libraries be linked correctly, you must also have dynamic libraries of the target variety, like MUSL libc.so
in place, and correctly set (LD_LIBRARY_PATH
etc.).
I made a thoroughly commented Dockerfile that builds my project statically with some native dependencies. It might be of help for others too.
https://github.com/golddranks/rust_musl_docker/blob/master/Dockerfile.template
add a comment |
If you want to statically link a Rust program without native dependencies, that is much easier:
$ rustup target add x86_64-unknown-linux-musl
$ cargo build --release --target=x86_64-unknown-linux-musl
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f40695010%2fhow-to-compile-a-static-musl-binary-of-a-rust-project-with-native-dependencies%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The problem was that for each crate providing a native dependency – say OpenSSL – there is the build.rs
build script that is in charge of communicating the build and linking options to Cargo and to rustc
. (For example: they print out something like cargo:rustc-link-lib=static=ssl
which Cargo then reads and acts accordingly.)
So, just setting the "standard" GCC environmental variables is hardly going to have any effect. You must check each and every build.rs
separately to know how to coerce that exact crate to convey cargo it's options. For OpenSSL, it's env vars like OPENSSL_DIR
, OPENSSL_STATIC
etc.
Another hurdle is that if you use compiler plugins, they might be compiled with the target triplet too (at least docker_codegen). On the other hand, they are linked dynamically during the compiling process. This mean that not only must static libraries be linked correctly, you must also have dynamic libraries of the target variety, like MUSL libc.so
in place, and correctly set (LD_LIBRARY_PATH
etc.).
I made a thoroughly commented Dockerfile that builds my project statically with some native dependencies. It might be of help for others too.
https://github.com/golddranks/rust_musl_docker/blob/master/Dockerfile.template
add a comment |
The problem was that for each crate providing a native dependency – say OpenSSL – there is the build.rs
build script that is in charge of communicating the build and linking options to Cargo and to rustc
. (For example: they print out something like cargo:rustc-link-lib=static=ssl
which Cargo then reads and acts accordingly.)
So, just setting the "standard" GCC environmental variables is hardly going to have any effect. You must check each and every build.rs
separately to know how to coerce that exact crate to convey cargo it's options. For OpenSSL, it's env vars like OPENSSL_DIR
, OPENSSL_STATIC
etc.
Another hurdle is that if you use compiler plugins, they might be compiled with the target triplet too (at least docker_codegen). On the other hand, they are linked dynamically during the compiling process. This mean that not only must static libraries be linked correctly, you must also have dynamic libraries of the target variety, like MUSL libc.so
in place, and correctly set (LD_LIBRARY_PATH
etc.).
I made a thoroughly commented Dockerfile that builds my project statically with some native dependencies. It might be of help for others too.
https://github.com/golddranks/rust_musl_docker/blob/master/Dockerfile.template
add a comment |
The problem was that for each crate providing a native dependency – say OpenSSL – there is the build.rs
build script that is in charge of communicating the build and linking options to Cargo and to rustc
. (For example: they print out something like cargo:rustc-link-lib=static=ssl
which Cargo then reads and acts accordingly.)
So, just setting the "standard" GCC environmental variables is hardly going to have any effect. You must check each and every build.rs
separately to know how to coerce that exact crate to convey cargo it's options. For OpenSSL, it's env vars like OPENSSL_DIR
, OPENSSL_STATIC
etc.
Another hurdle is that if you use compiler plugins, they might be compiled with the target triplet too (at least docker_codegen). On the other hand, they are linked dynamically during the compiling process. This mean that not only must static libraries be linked correctly, you must also have dynamic libraries of the target variety, like MUSL libc.so
in place, and correctly set (LD_LIBRARY_PATH
etc.).
I made a thoroughly commented Dockerfile that builds my project statically with some native dependencies. It might be of help for others too.
https://github.com/golddranks/rust_musl_docker/blob/master/Dockerfile.template
The problem was that for each crate providing a native dependency – say OpenSSL – there is the build.rs
build script that is in charge of communicating the build and linking options to Cargo and to rustc
. (For example: they print out something like cargo:rustc-link-lib=static=ssl
which Cargo then reads and acts accordingly.)
So, just setting the "standard" GCC environmental variables is hardly going to have any effect. You must check each and every build.rs
separately to know how to coerce that exact crate to convey cargo it's options. For OpenSSL, it's env vars like OPENSSL_DIR
, OPENSSL_STATIC
etc.
Another hurdle is that if you use compiler plugins, they might be compiled with the target triplet too (at least docker_codegen). On the other hand, they are linked dynamically during the compiling process. This mean that not only must static libraries be linked correctly, you must also have dynamic libraries of the target variety, like MUSL libc.so
in place, and correctly set (LD_LIBRARY_PATH
etc.).
I made a thoroughly commented Dockerfile that builds my project statically with some native dependencies. It might be of help for others too.
https://github.com/golddranks/rust_musl_docker/blob/master/Dockerfile.template
edited Nov 6 '17 at 7:39
answered Nov 20 '16 at 7:26
GolDDranksGolDDranks
9992920
9992920
add a comment |
add a comment |
If you want to statically link a Rust program without native dependencies, that is much easier:
$ rustup target add x86_64-unknown-linux-musl
$ cargo build --release --target=x86_64-unknown-linux-musl
add a comment |
If you want to statically link a Rust program without native dependencies, that is much easier:
$ rustup target add x86_64-unknown-linux-musl
$ cargo build --release --target=x86_64-unknown-linux-musl
add a comment |
If you want to statically link a Rust program without native dependencies, that is much easier:
$ rustup target add x86_64-unknown-linux-musl
$ cargo build --release --target=x86_64-unknown-linux-musl
If you want to statically link a Rust program without native dependencies, that is much easier:
$ rustup target add x86_64-unknown-linux-musl
$ cargo build --release --target=x86_64-unknown-linux-musl
edited Nov 15 '18 at 16:01
Shepmaster
156k14315457
156k14315457
answered Nov 15 '18 at 8:56
Arnout EngelenArnout Engelen
4,74311729
4,74311729
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f40695010%2fhow-to-compile-a-static-musl-binary-of-a-rust-project-with-native-dependencies%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I'm pretty sure the answer is: "you don't, easily". You will need to rebuild libpq and OpenSSL as static libraries (and linked to MUSL?). You then have to figure out how to change the corresponding Rust libraries to link to the static versions. I'm like 70% sure, but not completely.
– Shepmaster
Nov 19 '16 at 16:16
The thing is, I did rebuild them against MUSL, in the prefix
/usr/local/musl
. And I'm trying to get the corresponding libs to link to the static versions by trying to set the environment right, but apparently I'm failing. The way you put it sounds like I'd have to modify the libraries themselves, is that what you meant?– GolDDranks
Nov 19 '16 at 16:32
I mean, once you have compiled the MUSL versions of the C libraries (nicely done!), you will have to poke at each of the Rust bindings to figure out how to change how they link and to what. For example, openssl has environment variables.
– Shepmaster
Nov 19 '16 at 16:37
This was cross posted to Reddit.
– Shepmaster
Nov 19 '16 at 20:44
Thanks for the pointer about the environment variables! That was a crucial clue.
– GolDDranks
Nov 20 '16 at 7:27