How to compile a static musl binary of a Rust project with native dependencies?












4















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?










share|improve this question

























  • 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
















4















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?










share|improve this question

























  • 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














4












4








4








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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












2 Answers
2






active

oldest

votes


















7














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






share|improve this answer

































    -1














    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





    share|improve this answer

























      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
      });


      }
      });














      draft saved

      draft discarded


















      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









      7














      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






      share|improve this answer






























        7














        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






        share|improve this answer




























          7












          7








          7







          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






          share|improve this answer















          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







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 6 '17 at 7:39

























          answered Nov 20 '16 at 7:26









          GolDDranksGolDDranks

          9992920




          9992920

























              -1














              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





              share|improve this answer






























                -1














                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





                share|improve this answer




























                  -1












                  -1








                  -1







                  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





                  share|improve this answer















                  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






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Nov 15 '18 at 16:01









                  Shepmaster

                  156k14315457




                  156k14315457










                  answered Nov 15 '18 at 8:56









                  Arnout EngelenArnout Engelen

                  4,74311729




                  4,74311729






























                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      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





















































                      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







                      Popular posts from this blog

                      Xamarin.iOS Cant Deploy on Iphone

                      Glorious Revolution

                      Dulmage-Mendelsohn matrix decomposition in Python