Hacker News Reader

Comment by kwhitefoot | Hacker News Reader

$ 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

View on HN

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.

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.

An operating system from 2018 which is no longer maintained by its vendor? 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.

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.

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.

Are you sure you want glibc statically linked into your go executable ?

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.

Op's example however did use glibc though.

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.

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

Reply on news.ycombinator.com