3 ms·

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

• def- 12y ago
  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*
• loudmax 12y ago
  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.
  • ploxiln 12y ago
    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.
    • sunnyps 12y ago
      I thought gc only statically links and it was gccgo that had the ability to dynamically link.
      • ploxiln 12y ago
        gc only statically links to compiled go objects, and (may have changed recently? or soon?) only dynamically links to c libraries (via cgo).