8 ms·

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but th

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

synergy20 4y ago
very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great. I run a few Go apps, all are single executables, upgrading to new releases has never been easier. if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.
- dilyevsky 4y ago
  > CGO_ENABLED=1 CC=musl-gcc go build --ldflags '-linkmode external -extldflags=-static' Unless you cant use musl for some reason, but that’s a glibc problem, not Go
- aatd86 4y ago
  Some people are writing alternative via WebAssembly. For instance wazero which I'm really excited about. https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm_campaign=Wazero%20Launch&utm_content=242066038&utm_medium=social&utm_source=twitter&hss_channel=tw-998918265177952259 https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...
- cookiengineer 4y ago
  In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen. And there's also "purego" as an implementation that directly generates shellcode. Maybe those will help you, too? I am just mentioning these because for my use cases those approaches worked perfectly, CGO free. [1] https://github.com/Binject/debug https://github.com/Binject/debug [2] https://github.com/ebitengine/purego https://github.com/ebitengine/purego
  - synergy20 4y ago
    very useful,thanks
candiddevmike 4y ago
From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it. Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap. I wonder how much simpler Linux packaging would be if everything was statically linked...
- bzzzt 4y ago
  Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.
  - taeric 4y ago
    Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :( The docker world is a neat example of this. The stories of ${absurdly high percent} of containers having vulnerabilities only gets to claim that because of "unpatched libraries." If you reduce it to the number of containers with exploitable vulnerabilities, it is still non-zero, but not nearly as high.
    - nightfly 4y ago
      The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library
      - taeric 4y ago
        That is the thing, though. For most applications, those vulnerabilities in a common library are not relevant. That is what I was talking about in saying that it is in code that isn't used by them. You are, of course, right that it has the possibility of happening. But by and large, it doesn't happen there any more often than it does in the dynamically linked cases. And, by and large, the dynamically linked cases are often a lot more complicated to deploy. (Granted, deployment for either should be doable nowadays.) The dream, of course, is you just patch the library and call it a day. The reality seems to usually be a circus check on every application that you have deployed to see if they are impacted anyway.
quaintdev 4y ago
> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.
- adql 4y ago
  We used that to make a simple "VPN diagnostics" app for our helpdesk (app checked connectivity and config of the machine then displayed the summary page). Only thing that needed to be written per-os is how to call a browser to display the report
  - sconi 4y ago
    interesting. could you share what specifically the report had?
- lagniappe 4y ago
  I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now. Just do `release --name "mycoolprogram" --version "0.1.0"` and it will output all of your labeled release binaries for every platform your code supports. check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sports 40 different platform combos [1] [0] - https://github.com/donuts-are-good/release.sh https://github.com/donuts-are-good/release.sh [1] - https://github.com/donuts-are-good/bearclaw/releases/latest https://github.com/donuts-are-good/bearclaw/releases/latest
  - superb-owl 4y ago
    looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.
    - lagniappe 4y ago
      Thanks for checking it out :) I'm not going to pretend I haven't been refreshing the page waiting for bugs and comments
traceroute66 4y ago
[flagged]
- tptacek 4y ago
  Please don't start random language fights.
  - tomcam 4y ago
    Directly addressing the topic of a upvoted article is starting random language fights?
    - doodpants 4y ago
      The article is about Go, and while the article mentions other languages for comparison, Rust is not one of them. So traceroute66's comment comes across as starting a Rust vs. Go fight where not appropriate.
      - djbusby 4y ago
        Not even, they just expressing an opinion.
      - tomcam 4y ago
        Doesn’t come across as starting a fight to me. Not even close.
        deleted 4y ago
        [deleted]
      - AmpsterMan 4y ago
        I think the comparison is totally apt and illustrates why Rust and Go get compared very often. They are both languages that compile to a binary, rather than running in a managed environment.
    - 4y ago
shp0ngle 4y ago
You can still do that with musl, can’t you? Can make a static c binary with that
1vuio0pswjnm7 4y ago
IME, using musl, compiling static binaries written in C is as easy as it was before glibc changes and as it has always has been on NetBSD. I compile static binaries written in C every day on Linux. I never encountered any problems compiling static binaries on BSD.
- nneonneo 4y ago
  That’s great if your only dependency is libc. It gets progressively harder the more dependencies you need, and it becomes downright untenable the moment you run into some dependency with a dlopen-based plugin architecture.
- drewg123 4y ago
  Can you link something substantial, like Firefox, statically on NetBSD?
  - 1vuio0pswjnm7 4y ago
    Compiling Firefox on NetBSD (dynamically) takes longer than compiling the kernel, maybe even longer than compiling an entire base system. It's been a long time since I tried it but it just took far too long so I lost interest. Granted, the computers I use have limited resources. Anyway, I gave up on graphical browsers many years ago. It seems I prefer "unsubstantial" programs.
    - 1vuio0pswjnm7 4y ago
      Graphical web browsers from "tech" companies (and their partners, like Mozilla) are too large, too complex, too difficult for the user to control. IMHO.
  - deleted 4y ago
    [deleted]
- 1vuio0pswjnm7 4y ago
  Many of the static binaries I use rely on dependencies other than libc. Most are small programs. Out of personal preference, I generally try to avoid large programs with numerous dependencies. Exception might be something like ffmpeg. Static binary for the author is 21M but package from repository is 84M so the static binary uses less space. ffmpeg has many dependencies besides libc.
caeril 4y ago
This is generally only true with CGO_ENABLED=0. I've found many times that a go binary, even if it has no cgo or cgo dependencies, will randomly require glibc on the target system to execute if you don't explicitly disable cgo in your build.

synergy20 4y ago

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great. I run a few Go apps, all are single executables, upgrading to new releases has never been easier. if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

dilyevsky 4y ago
> CGO_ENABLED=1 CC=musl-gcc go build --ldflags '-linkmode external -extldflags=-static' Unless you cant use musl for some reason, but that’s a glibc problem, not Go
aatd86 4y ago
Some people are writing alternative via WebAssembly. For instance wazero which I'm really excited about. https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm_campaign=Wazero%20Launch&utm_content=242066038&utm_medium=social&utm_source=twitter&hss_channel=tw-998918265177952259 https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...
cookiengineer 4y ago
In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen. And there's also "purego" as an implementation that directly generates shellcode. Maybe those will help you, too? I am just mentioning these because for my use cases those approaches worked perfectly, CGO free. [1] https://github.com/Binject/debug https://github.com/Binject/debug [2] https://github.com/ebitengine/purego https://github.com/ebitengine/purego
- synergy20 4y ago
  very useful,thanks

candiddevmike 4y ago

From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it. Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap. I wonder how much simpler Linux packaging would be if everything was statically linked...

bzzzt 4y ago
Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.
- taeric 4y ago
  Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :( The docker world is a neat example of this. The stories of ${absurdly high percent} of containers having vulnerabilities only gets to claim that because of "unpatched libraries." If you reduce it to the number of containers with exploitable vulnerabilities, it is still non-zero, but not nearly as high.
  - nightfly 4y ago
    The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library
    - taeric 4y ago
      That is the thing, though. For most applications, those vulnerabilities in a common library are not relevant. That is what I was talking about in saying that it is in code that isn't used by them. You are, of course, right that it has the possibility of happening. But by and large, it doesn't happen there any more often than it does in the dynamically linked cases. And, by and large, the dynamically linked cases are often a lot more complicated to deploy. (Granted, deployment for either should be doable nowadays.) The dream, of course, is you just patch the library and call it a day. The reality seems to usually be a circus check on every application that you have deployed to see if they are impacted anyway.

quaintdev 4y ago

> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.

adql 4y ago
We used that to make a simple "VPN diagnostics" app for our helpdesk (app checked connectivity and config of the machine then displayed the summary page). Only thing that needed to be written per-os is how to call a browser to display the report
- sconi 4y ago
  interesting. could you share what specifically the report had?
lagniappe 4y ago
I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now. Just do `release --name "mycoolprogram" --version "0.1.0"` and it will output all of your labeled release binaries for every platform your code supports. check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sports 40 different platform combos [1] [0] - https://github.com/donuts-are-good/release.sh https://github.com/donuts-are-good/release.sh [1] - https://github.com/donuts-are-good/bearclaw/releases/latest https://github.com/donuts-are-good/bearclaw/releases/latest
- superb-owl 4y ago
  looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.
  - lagniappe 4y ago
    Thanks for checking it out :) I'm not going to pretend I haven't been refreshing the page waiting for bugs and comments

traceroute66 4y ago

[flagged]

tptacek 4y ago
Please don't start random language fights.
- tomcam 4y ago
  Directly addressing the topic of a upvoted article is starting random language fights?
  - doodpants 4y ago
    The article is about Go, and while the article mentions other languages for comparison, Rust is not one of them. So traceroute66's comment comes across as starting a Rust vs. Go fight where not appropriate.
    - djbusby 4y ago
      Not even, they just expressing an opinion.
    - tomcam 4y ago
      Doesn’t come across as starting a fight to me. Not even close.
      - deleted 4y ago
        [deleted]
    - AmpsterMan 4y ago
      I think the comparison is totally apt and illustrates why Rust and Go get compared very often. They are both languages that compile to a binary, rather than running in a managed environment.
  - 4y ago

shp0ngle 4y ago

You can still do that with musl, can’t you? Can make a static c binary with that

1vuio0pswjnm7 4y ago

IME, using musl, compiling static binaries written in C is as easy as it was before glibc changes and as it has always has been on NetBSD. I compile static binaries written in C every day on Linux. I never encountered any problems compiling static binaries on BSD.

nneonneo 4y ago
That’s great if your only dependency is libc. It gets progressively harder the more dependencies you need, and it becomes downright untenable the moment you run into some dependency with a dlopen-based plugin architecture.
drewg123 4y ago
Can you link something substantial, like Firefox, statically on NetBSD?
- 1vuio0pswjnm7 4y ago
  Compiling Firefox on NetBSD (dynamically) takes longer than compiling the kernel, maybe even longer than compiling an entire base system. It's been a long time since I tried it but it just took far too long so I lost interest. Granted, the computers I use have limited resources. Anyway, I gave up on graphical browsers many years ago. It seems I prefer "unsubstantial" programs.
  - 1vuio0pswjnm7 4y ago
    Graphical web browsers from "tech" companies (and their partners, like Mozilla) are too large, too complex, too difficult for the user to control. IMHO.
- deleted 4y ago
  [deleted]
1vuio0pswjnm7 4y ago
Many of the static binaries I use rely on dependencies other than libc. Most are small programs. Out of personal preference, I generally try to avoid large programs with numerous dependencies. Exception might be something like ffmpeg. Static binary for the author is 21M but package from repository is 84M so the static binary uses less space. ffmpeg has many dependencies besides libc.

caeril 4y ago

This is generally only true with CGO_ENABLED=0. I've found many times that a go binary, even if it has no cgo or cgo dependencies, will randomly require glibc on the target system to execute if you don't explicitly disable cgo in your build.