Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

Post reply on HN
Print view View original

481–490 of 493 posts

Re: Loss32: Let's Build a Win32/Linux

#481

Post by account42 »

forrestthewoods wrote: post #337
ben-schaaf wrote: post #224

Earlier quoted context omitted.

Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.

> Only because people aren't putting in the effort to build their binaries properly. Because Linux userland is an unmitigated clusterfuck of bad design that makes this really really really hard. GCC/Clang and Glibc make it effectively impossible almost impossible to do this on their own. The only way you can actually do this is: 1. create a userland container from the past 2. use Zig which moved oceans and mountains…

This is not a problem with the userland, but with the SDK - or rather a lack of one.

Re: Loss32: Let's Build a Win32/Linux

#482

Post by account42 »

LegionMammal978 wrote: post #311
ben-schaaf wrote: post #224

Earlier quoted context omitted.

Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.

But to link against an old glibc version, you need to compile on an old distro, on a VM. And you'll have a rough time if some part of the build depends on a tool too new for your VM. It would be infinitely simpler if one could simply 'cross-compile' down to older symbol versions, but the tooling does not make this easy at all.

> you need to compile on an old distro

Wrong.

> on a VM.

Wrong.

Cross-compiling is a thing.

Re: Loss32: Let's Build a Win32/Linux

#483

Post by account42 »

imtringued wrote: post #449
nineteen999 wrote: post #364

Earlier quoted context omitted.

I'm not disagreeing that glibc symbol versioning could be better. I raised it because this is probably one of the few valid use cases for containers where they would have a large advantage over a heavyweight VM. But it's like complaining that you might need a VM or container to compile your software for Win16 or Win32s. Nobody is using those anymore. Nor really old Linux distributions. And if they do, they're not rea…

>As C/C++ programmer, the thing I notice is ... the people who complain about this most loudly are the web dev crowd who don't speak C/C++, when some ancient game doesn't work on their obscure Arch/Gentoo/Ubuntu distribution and they don't know how to fix it. Boo hoo. You must really be behind the times. Arch and Gentoo users wouldn't complain because an old game doesn't run. In fact the exact opposite would happen.…

Glibc strives for backwards (but not forwards) compatibility so barring exceptions (which are extremely rare but nobody is perfect), using a newer glibc than what something was built for does not cause any issues, only using an older glibc would.

Re: Loss32: Let's Build a Win32/Linux

#484

Post by account42 »

chrismorgan wrote: post #423
rcxdude wrote: post #412

Earlier quoted context omitted.

Individual functions may have a lot of different versions. They do only update them if there is an ABI change (so you may have e.g. f1_v1, f1_v2, f2_v2, f2_v3 as synbols in v3 of glibc) but there's no easy way to say 'give me v2 of every function'. If you compile against v3 you'll get f2_v3 and f1_v2 and so it won't work on v2.

Why are they changing? And I presume there must be disadvantages to staying on the old symbols, or else they wouldn’t be changing them—so what are those disadvantages?

Depends on the functions. One example is memcpy - the API specifies that the source and destination must not overlap but the original implementation in glibc didn't care. When they wanted to optimize the implementation they decided to introduce a new version of memcpy rather than breaking older binaries that inadvertently relied on on the existing behavior even if that was never guaranteed by the API. Old binaries keep getting the older but slower memcpy, new binaries get the optimized memcpy.

Other examples are keeping bug compatibility, when standards are revised to require incompatible behavior, or to introduce additional safety features that require additional (hidden) arguments automatically passed to functions which changes their ABI.

Re: Loss32: Let's Build a Win32/Linux

#485

Post by account42 »

rcxdude wrote: post #413
jhasse wrote: post #368

Earlier quoted context omitted.

You can choose the version. There was apgcc from the (now dead) Autopackage project which did just that: https://github.com/DeaDBeeF-Player/apbuild

It's not at all straightforward, it should be the kind of thing that's just a compiler flag, as opposed to needing to restructure your build process to support it.

It's not straightforward and yes it should be easier, but it's also not rocket science. Containers have made it approachable for the average developer.

Re: Loss32: Let's Build a Win32/Linux

#486

Post by account42 »

grishka wrote: post #430
rcxdude wrote: post #413

Earlier quoted context omitted.

It's not at all straightforward, it should be the kind of thing that's just a compiler flag, as opposed to needing to restructure your build process to support it.

Yeah that's what I meant. I also came across some script with redefinitions of C standard library functions that supposedly also allows you to link against older glibc symbols. I couldn't make it work. Any half-decent SDK should allow you to trivially target an older platform version, but apparently doing trivial-seeming things without suffering is not The Linux Way™.

The reason that there is no SDK is because containers (and before that sysroots) are good enough that no one bothers to maintain the 100% usability solution.

Re: Loss32: Let's Build a Win32/Linux

#487

Post by account42 »

hulitu wrote: post #471
senfiaj wrote: post #50

This might offend some people but even Linus Torvalds thinks that the ABI compatibility is not good enough in Linux distros, and this is one of the main reasons Linux is not popular on the desktop. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s

> the ABI compatibility is not good enough in Linux distros surely forced versioning of GLIBC didn't help. "This program requires GLIBC_2.33"

It did help for programs built by those who know what they are doing. It doesn't magically fix developer incompetence/ignorance.

Re: Loss32: Let's Build a Win32/Linux

#488

Post by account42 »

JoshTriplett wrote: post #171
qcnguy wrote: post #106

Earlier quoted context omitted.

It's really just not. GTK is on its fourth major version. Wayland broke backwards compatibility with tons of apps.

The difference is that you can statically link GTK+, and it'll work. You can't statically link glibc, if you want to be able to resolve hostnames or users, because of NSS modules.

You statically linked GTK+ won't work with the users UI styles though and probably won't support everyone's input methods or accessibility tools.

Re: Loss32: Let's Build a Win32/Linux

#489

Post by account42 »

amelius wrote: post #97
duped wrote: post #65

Earlier quoted context omitted.

It's really just glibc

Can't we just freeze glibc, at least from an API version perspective?

The people will complain that glibc doesn't implement what they want.

The solution is simply to build against the oldest glibc version you want to support - we should focus on making that simpler, ideally just a compiler flag.

Re: Loss32: Let's Build a Win32/Linux

#490

Post by account42 »

johncolanduoni wrote: post #466
uecker wrote: post #460

Earlier quoted context omitted.

Is it painful? Why? You need a build environment that has the old libraries. It does not have to be ancient, just exactly what you need.

It has to be as ancient as the oldest glibc you want to support, usually a Red Hat release with very old version and manual security backports. These can have nearly decade-old glibc versions, especially if you care about extended support contracts. You generally have difficulty actually running contemporary build tools on such a thing, so the workaround is to use —-sysroot against what is basically a chroot of the o…

The glibc has to be as ancient as the oldest one you want to support. The rest does not.
Post reply on HN