4 ms·

$ spf spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by spf) spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not foun

$ spf spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by spf) spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by spf) I'm on Linux Mint 19

mcbuilder 2y ago
This is a linking issue (you're missing a specific version of a dynamically linked standard library), and probably best in the issues on the repo, not Hacker News.
antihero 2y ago
They could build it with CGO_ENABLED=0, if they are using Alpine, perhaps.
opheliate 2y ago
An operating system from 2018 which is no longer maintained by its vendor? https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php I think it's somewhat unreasonable to expect software released today will necessarily work on your environment without some legwork.
- isopede 2y ago
  Is it though? I can run Windows programs from 20 years ago on my Windows machine just fine. Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorry state of affairs. Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.
  - donio 2y ago
    You are talking about backward compatibility, the parent thread is about forward compatibility. You won't have much luck running a modern executable on XP unless the vendor went out of their way to make that happen. > What's worse is that you can't even really statically link it without herculean effort. The program we are discussing happens to be written in Go so it's trivial to build a statically linked executable.
    - worthless-trash 2y ago
      Are you sure you want glibc statically linked into your go executable ?
      - donio 2y ago
        glibc won't be used at all. With Go on Linux libc is only needed when the libc DNS resolver is used (instead of Go's built-in one) or if C libraries are used. superfile doesn't need either of these so it's very simple to build it as a pure Go executable which will be statically linked and contain no C code at all.
        worthless-trash 2y ago
        Op's example however did use glibc though.
  - qwery 2y ago
    It's an interesting comparison. I agree that five years is well within the expected period of viability of an operating system. Some points to consider: - any given release of a Linux distro will probably work on hardware released five years earlier -- one factor that reduces the cost of upgrading the OS (there are many more obvious factors) - Microsoft is highly motivated to get customers to upgrade to the new Windows at the time. The legacy support is well-known as a "bone" (or: "a factor that reduces the cost of upgrading the OS") - binary backwards/forwards compatibility is less of an issue in an environment that doesn't treat source code as a secret - why run old versions of software? In other words: xterm is older than Windows and also as new as Windows Also, I've always found it amusing that I have much less trouble running old windows software on a Linux (wine) than on new versions of windows.
colatkinson 2y ago
Your version of glibc is too old. Mint 19 is based off Ubuntu 18.04, which ships glibc 2.27, whereas this binary seems to require symbol versions first shipped in glibc 2.34. You'll have to compile from source, or update your distro to a maintained version. Ubuntu 22.04 ships glibc 2.35, and so Mint 21 should work. Mostly commenting because while this isn't really a tech support channel, being able to identify glibc version mismatch errors comes up extremely often, even in this day and age.

mcbuilder 2y ago

This is a linking issue (you're missing a specific version of a dynamically linked standard library), and probably best in the issues on the repo, not Hacker News.

antihero 2y ago

They could build it with CGO_ENABLED=0, if they are using Alpine, perhaps.

opheliate 2y ago

An operating system from 2018 which is no longer maintained by its vendor? https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php I think it's somewhat unreasonable to expect software released today will necessarily work on your environment without some legwork.

isopede 2y ago
Is it though? I can run Windows programs from 20 years ago on my Windows machine just fine. Issues with Linux binary distribution meanwhile are ubiquitous, with glibc probably being the single biggest offender. What's worse is that you can't even really statically link it without herculean effort. I've spent an inordinate amount of my life trying to wrangle third-party binaries on Linux libraries and it's just a sorry state of affairs. Try taking a binary package from a vendor from even just 5 years ago and there's a non-zero chance it won't run on your modern distro.
- donio 2y ago
  You are talking about backward compatibility, the parent thread is about forward compatibility. You won't have much luck running a modern executable on XP unless the vendor went out of their way to make that happen. > What's worse is that you can't even really statically link it without herculean effort. The program we are discussing happens to be written in Go so it's trivial to build a statically linked executable.
  - worthless-trash 2y ago
    Are you sure you want glibc statically linked into your go executable ?
    - donio 2y ago
      glibc won't be used at all. With Go on Linux libc is only needed when the libc DNS resolver is used (instead of Go's built-in one) or if C libraries are used. superfile doesn't need either of these so it's very simple to build it as a pure Go executable which will be statically linked and contain no C code at all.
      - worthless-trash 2y ago
        Op's example however did use glibc though.
- qwery 2y ago
  It's an interesting comparison. I agree that five years is well within the expected period of viability of an operating system. Some points to consider: - any given release of a Linux distro will probably work on hardware released five years earlier -- one factor that reduces the cost of upgrading the OS (there are many more obvious factors) - Microsoft is highly motivated to get customers to upgrade to the new Windows at the time. The legacy support is well-known as a "bone" (or: "a factor that reduces the cost of upgrading the OS") - binary backwards/forwards compatibility is less of an issue in an environment that doesn't treat source code as a secret - why run old versions of software? In other words: xterm is older than Windows and also as new as Windows Also, I've always found it amusing that I have much less trouble running old windows software on a Linux (wine) than on new versions of windows.

colatkinson 2y ago

Your version of glibc is too old. Mint 19 is based off Ubuntu 18.04, which ships glibc 2.27, whereas this binary seems to require symbol versions first shipped in glibc 2.34. You'll have to compile from source, or update your distro to a maintained version. Ubuntu 22.04 ships glibc 2.35, and so Mint 21 should work. Mostly commenting because while this isn't really a tech support channel, being able to identify glibc version mismatch errors comes up extremely often, even in this day and age.