Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

I couldn't tell if the Nim result was actually statically linked. If it was, then it almost certainly wasn't using glibc, because the binary would certainly be much fatter.

View on HN

The Nim binary dynamically links against glibc and SDL2. If you really want to statically link against a C standard library, musl works just fine:

    @if musl:
      passL = "-static"
      gcc.exe = "/usr/local/musl/bin/musl-gcc"
      gcc.linkerexe = "/usr/local/musl/bin/musl-gcc"
    @end

Now it compiles like this (SDL2 is still dynamically loaded, +1 MB for that):

    $ nim -d:release -d:musl c src/nimes
    $ ls -lha src/nimes
    -rwxr-xr-x 1 def users 219K Mai  1 22:00 src/nimes*

If the Nim binary is dynamically linked, comparing the size to a Go binary isn't always valid. There are reasonable trade-offs to consider when selecting dynamic vs static linking. Admittedly, when you're running an NES emulator on your desktop probably isn't one of them, you're not likely to care either way.

The Nim -> C -> emscripten path is very impressive. Kudos.

Go also dynamically links glibc by default on linux, for the domain name resolver functions.

I'm not sure what Go does on OS X, but I know that it's not possible to statically link the c library on OS X.

I thought gc only statically links and it was gccgo that had the ability to dynamically link.

gc only statically links to compiled go objects, and (may have changed recently? or soon?) only dynamically links to c libraries (via cgo).

Reply on news.ycombinator.com