<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    While I also like static binaries, most people do not necessarily
    need or want them -- changing the default for GHC to be built with
    musl would be a huge risk, IMO. More concretely, while GHC has a
    maintained alpine linux package (which is based on musl), stack does
    not -- see <a class="moz-txt-link-freetext" href="https://github.com/commercialhaskell/stack/issues/2387">https://github.com/commercialhaskell/stack/issues/2387</a>.<br>
    <br>
    I've written about it a little bit
(<a class="moz-txt-link-freetext" href="https://vadosware.io/post/static-binaries-for-haskell-a-convoluted-approach/">https://vadosware.io/post/static-binaries-for-haskell-a-convoluted-approach/</a>),
    the post is quite old so things have likely shifted. <br>
    <br>
    Static linking for programs in linux is surprisingly hard (but
    possible with some caveats), even when you get a library linked with
    musl (or some other small libc) you often need to ensure that libnss
    is available if you're going to do dns resolutions. One alternative
    that looks viable is nsss (<a class="moz-txt-link-freetext" href="https://skarnet.org/software/nsss">https://skarnet.org/software/nsss</a>), but
    I've never actually used it -- other languages like rust and go get
    around this by offering domain name resolution at the language level
    (<a class="moz-txt-link-freetext" href="https://doc.rust-lang.org/std/net/trait.ToSocketAddrs.html">https://doc.rust-lang.org/std/net/trait.ToSocketAddrs.html</a>,
    <a class="moz-txt-link-freetext" href="https://golang.org/pkg/net/#hdr-Name_Resolution">https://golang.org/pkg/net/#hdr-Name_Resolution</a>). I'm not entirely
    sure how easy this would be to do with haskell -- is the move to
    make a haskell binding to nsss then using that? How easy is it to
    write a haskell library that will include the relevant headers that
    make nsss go? Here's the quick rundown on how one uses nsss:<br>
    <br>
    > Application programs can use the internal API directly, or
    the prefixed <tt>nsss_</tt> functions directly. Most programs,
    however, will simply use the standard
    <a
href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pwd.h.html">pwd.h</a>,
    <a
href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/grp.h.html">grp.h</a>
    or
    <a href="http://man7.org/linux/man-pages/man3/getspnam.3.html">shadow.h</a>
    interfaces. nsss provides a version of these standard headers: if an
    application is built with these headers, then <tt>getpwnam()</tt>
    will automatically be aliased to <tt>nsss_all_getpwnam()</tt>, and
    the other functions will be aliased similarly.
    <br>
    <br>
    Also, a cabal-based workflow might be better for building static
    haskell binaries -- it's normally included with containers that have
    the toolchain set up already like
    <a class="moz-txt-link-freetext" href="https://github.com/utdemir/ghc-musl">https://github.com/utdemir/ghc-musl</a> (but as I mentioned earlier,
    stack is not).<br>
    <br>
    I *think* you could somewhat easily get stack to build a musl
    derived binary by using the stack docker integration
    (<a class="moz-txt-link-freetext" href="https://docs.haskellstack.org/en/stable/docker_integration/">https://docs.haskellstack.org/en/stable/docker_integration/</a>) --
    again, I haven't tried this but it'd be a good subject of a blog
    post at some point.<br>
    <br>
    Victor<br>
    <br>
    <div class="moz-cite-prefix">On 3/10/20 2:10 PM, Nutr1t07 wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:HK0PR02MB3393A530DD9435481B94816D83FF0@HK0PR02MB3393.apcprd02.prod.outlook.com">It's
      pretty weird that program compiled with '-optl-static' runs just
      well on my server Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-48-generic
      x86_64), but failed running on my PC Archlinux (x86_64 Linux
      5.5.8-arch1-1).
      <br>
      <br>
      Since there are static compiling problems with glibc, why is the
      GHC in stack is still built with ghlic instead of musl?
      <br>
      <br>
      On 3/10/20 11:24 AM, Vanessa McHale wrote:
      <br>
      <blockquote type="cite">I’ve run into that before; I think it
        arises because you can’t link statically against libc? In any
        case, trying to use network code fails with a segfault.
        <br>
        <br>
        I think it is hard to work around; you need to build GHC against
        musl and then use that to compile your program.
        <br>
        <br>
        Cheers,
        <br>
        Vanessa
        <br>
        <br>
        <blockquote type="cite">On Mar 9, 2020, at 9:32 PM, Nutr1t07
          <a class="moz-txt-link-rfc2396E" href="mailto:nutr1t07@outlook.com"><nutr1t07@outlook.com></a> wrote:
          <br>
          <br>
          Hi,
          <br>
          <br>
          I added '-optl-static' in GHC option to make my program
          compiled statically. When I compiled the following code using
          'stack build':
          <br>
          <br>
          -- Main.hs
          <br>
          <br>
          {-# LANGUAGE OverloadedStrings #-}
          <br>
          module Main where
          <br>
          <br>
          import Web.Scotty                     as Scotty
          <br>
          import Network.Wreq                as Wreq
          <br>
          import Control.Monad.IO.Class
          <br>
          <br>
          main :: IO ()
          <br>
          main = scotty 8443 $ do
          <br>
             Scotty.get (literal "/") $ do
          <br>
               _ <- liftIO $ Wreq.get <a class="moz-txt-link-rfc2396E" href="https://www.google.com/">"https://www.google.com/"</a>
          <br>
               html "Could not see this"
          <br>
          <br>
          --
          <br>
          <br>
          Ran the compiled program and accessing <a class="moz-txt-link-rfc2396E" href="http://localhost:8443">"http://localhost:8443"</a>
          would raise a segmentation fault.
          <br>
          <br>
          Here are what in my 'ghc-option':
          <br>
          <br>
               ghc-options:
          <br>
               - -optl-static
          <br>
               - -threaded
          <br>
               - -rtsopts
          <br>
               - -with-rtsopts=-N
          <br>
          <br>
          Then I removed the '-optl-static', compiled it, and the
          program ran well.
          <br>
          <br>
          It seems that it something has to do with glibc. What can I do
          with this problem?
          <br>
          <br>
          Regards
          <br>
          <br>
          PS. I'm using GHC 8.8.2, stack 2.1.3
          <br>
          <br>
          _______________________________________________
          <br>
          Haskell-Cafe mailing list
          <br>
          To (un)subscribe, modify options or view archives go to:
          <br>
          <a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
          <br>
          Only members subscribed via the mailman list are allowed to
          post.
          <br>
        </blockquote>
      </blockquote>
      _______________________________________________
      <br>
      Haskell-Cafe mailing list
      <br>
      To (un)subscribe, modify options or view archives go to:
      <br>
      <a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
      <br>
      Only members subscribed via the mailman list are allowed to post.<br>
    </blockquote>
    <br>
  </body>
</html>