6 ms·

Static linking is easily available with C/C++ as well. The main trade-off is how critical bugs in some library your program uses can be solved. With dynamic li

by Strom 14y ago

Static linking is easily available with C/C++ as well. The main trade-off is how critical bugs in some library your program uses can be solved. With dynamic linking it's possible for the library author to publish an API-compatible update, which when deployed fixes the issue in all programs that use this library. With static linking you need to recompile the whole program and publish the update. For real world examples you could look at the Microsoft C run-time. When a security vulnerability is found & fixed, Microsoft pushes the dynamic link version of the update via Microsoft Update and millions of programs are no longer affected by this issue. However when you linked statically, you need to update your program as well. Many programs do not have good automatic update systems, and many programs aren't even under continued maintenance and remain forever vulnerable.

jkn 14y ago
Static linking is not easily available with C/C++ in the general case. Some libraries support it, some important ones like Glibc and GTK+ do not.
- pjmlp 14y ago
  The only reason this is not an issue with Go is that the language is too young and the reference compiler only supports static linking fot the time being. The moment the compiler starts supporting dynamic linking the same will happen to Go.
  - 4ad 14y ago
    Static linking of Go code is a conscious design decision, not some artifact of toolchain immaturity. It will never change.
    - reddit_clone 14y ago
      On a related note, using Go can one develop DLLs that can be dynamically consumed from other applications? Or you can only produce statically linked exe's?
      - zimbatm 14y ago
        Only exes at the time being. Go is the main loop and needs to have control of the execution flow for concurrency. If you think of it, DLLs are a bit like separate programs that you communicate with trough the C call stack instead of another structured protocol. In Go you would spawn different processes and use something like protobuf to exchange messages.
    - pjmlp 14y ago
      You can make use of dynamic linking with gccgo, as far as I am aware.
  - koenigdavidmj 14y ago
    The Plan 9 people (basically the same group as the Go people) have some philosophical problems with dynamic linking. Read http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ for their arguments.
- johnm 14y ago
  Makes the choice of using them that much easier. :-)
- 1amzave 14y ago
  Huh? Perhaps you mean Glib? Static linking works just fine with glibc: [me@host: tmp]% cat > hello.c #include <stdio.h> int main(void) { printf("hello world\n"); return 0; } [me@host: tmp]% gcc -o hello -Wall hello.c -static [me@host: tmp]% file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, not stripped [me@host: tmp]% ldd hello not a dynamic executable [me@host: tmp]% ./hello hello world
  - saurik 14y ago
    I largely agree with you, but for what it's worth, that doesn't "just work": there are places in glibc that use dlopen to pull in modular code; one example is the DNS resolver.
  - tedunangst 14y ago
    As mentioned, if you try that it works less than 100%. Trying to run a 32-bit program on a 64-bit host will fail in weird ways unless some of the expected bonus libraries are available.
- gillianseed 14y ago
  Although I've never tried it myself I've read that gtk supports static linking, iirc you have to build gtk with --disable-modules. Also, Go has gtk bindings, how does that work?
  - tedunangst 14y ago
    Go can dynanmically load C libraries I believe, but there is no support for native shared go code.
    - 4ad 14y ago
      That is correct.
  - jkn 14y ago
    Ah you're right, it seems you can get a static build by recompiling GTK+ and its dependencies with the appropriate flags and some extra manipulation... See http://wiki.inkscape.org/wiki/index.php/CompilingStatic http://wiki.inkscape.org/wiki/index.php/CompilingStatic for an outdated example. I don't know if that would work on Windows, it used to be not supported: http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/5388.html http://readlist.com/lists/lists.sourceforge.net/mingw-users/...
Splines 14y ago
I wonder if there's a way to have your cake and eat it too. Publish your app as a dynamically linked binary to an app publisher, the publisher takes your dll and mashes it with its dependencies into a single dll that they deliver to the customer. When there is a security update in a dependent dll, a new binary can be delivered by the publisher to the customer with no need for the original author to push a button. I'm guessing something like this exists already?

by Strom 14y ago

jkn 14y ago

Static linking is not easily available with C/C++ in the general case. Some libraries support it, some important ones like Glibc and GTK+ do not.

pjmlp 14y ago
The only reason this is not an issue with Go is that the language is too young and the reference compiler only supports static linking fot the time being. The moment the compiler starts supporting dynamic linking the same will happen to Go.
- 4ad 14y ago
  Static linking of Go code is a conscious design decision, not some artifact of toolchain immaturity. It will never change.
  - reddit_clone 14y ago
    On a related note, using Go can one develop DLLs that can be dynamically consumed from other applications? Or you can only produce statically linked exe's?
    - zimbatm 14y ago
      Only exes at the time being. Go is the main loop and needs to have control of the execution flow for concurrency. If you think of it, DLLs are a bit like separate programs that you communicate with trough the C call stack instead of another structured protocol. In Go you would spawn different processes and use something like protobuf to exchange messages.
  - pjmlp 14y ago
    You can make use of dynamic linking with gccgo, as far as I am aware.
- koenigdavidmj 14y ago
  The Plan 9 people (basically the same group as the Go people) have some philosophical problems with dynamic linking. Read http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ for their arguments.
johnm 14y ago
Makes the choice of using them that much easier. :-)
1amzave 14y ago
Huh? Perhaps you mean Glib? Static linking works just fine with glibc: [me@host: tmp]% cat > hello.c #include <stdio.h> int main(void) { printf("hello world\n"); return 0; } [me@host: tmp]% gcc -o hello -Wall hello.c -static [me@host: tmp]% file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, not stripped [me@host: tmp]% ldd hello not a dynamic executable [me@host: tmp]% ./hello hello world
- saurik 14y ago
  I largely agree with you, but for what it's worth, that doesn't "just work": there are places in glibc that use dlopen to pull in modular code; one example is the DNS resolver.
- tedunangst 14y ago
  As mentioned, if you try that it works less than 100%. Trying to run a 32-bit program on a 64-bit host will fail in weird ways unless some of the expected bonus libraries are available.
gillianseed 14y ago
Although I've never tried it myself I've read that gtk supports static linking, iirc you have to build gtk with --disable-modules. Also, Go has gtk bindings, how does that work?
- tedunangst 14y ago
  Go can dynanmically load C libraries I believe, but there is no support for native shared go code.
  - 4ad 14y ago
    That is correct.
- jkn 14y ago
  Ah you're right, it seems you can get a static build by recompiling GTK+ and its dependencies with the appropriate flags and some extra manipulation... See http://wiki.inkscape.org/wiki/index.php/CompilingStatic http://wiki.inkscape.org/wiki/index.php/CompilingStatic for an outdated example. I don't know if that would work on Windows, it used to be not supported: http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/5388.html http://readlist.com/lists/lists.sourceforge.net/mingw-users/...

Splines 14y ago

I wonder if there's a way to have your cake and eat it too. Publish your app as a dynamically linked binary to an app publisher, the publisher takes your dll and mashes it with its dependencies into a single dll that they deliver to the customer. When there is a security update in a dependent dll, a new binary can be delivered by the publisher to the customer with no need for the original author to push a button. I'm guessing something like this exists already?