undefined | Better HN

0 pointsHexDecOctBin1mo ago0 comments

> The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it

What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653

Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first laptop)?

    __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");

0 comments

eqvinox1mo ago

> https://sourceware.org/bugzilla/show_bug.cgi?id=32653

dlopen and dlmopen no longer make the stack executable if a shared library requires it

I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I would call something that affects primarily closed source binaries (and mono on i386) a "huge" issue either.

The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything.

> __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");

A 12 year old forward compatibility issue that is fixed by upgrading glibc, okay. (Note this is the same timeframe as the s390 thing I linked.) I guess people shipping binaries need to be aware of it if they want to support glibc pre-2.2.14. That said, the general rule of shipping binaries is that you need to assume whatever you build against becomes the minimum required version, anything else is a gift.

I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?

manwe1501mo ago

A few recent examples: many distros changed the flag for emuTLS on Windows, which gcc implemented as a hard ABI break for no essential reason. If you compile for enough platforms, it will print various notes that various alignments have changed in the struct, which has caused grief numerous times in the past few years for people I work with (many of the changes don’t come with notes, they just change alignment since new hardware comes out that has new features which need more and/or there were bugs previously, so they silently change it). There’s also win32 or posix threading, and sjlj vs structured exceptions, all of which are mutually incompatible. Oh, and then don’t get me started on ARM v6 atomics, which is some weird decided-based-on-compiler-flags-to-record-heuristics-detected-during-configure-of-some-auxiliary-header time, instead of using the current target’s ABI

Sure, the ABI does not change at all, if you know in advance where the landmines are. Though it does have quite few, especially for a large project with a huge surface area

eqvinox1mo ago

I was talking about glibc; none of the things you mention relate to that. (Note glibc is not used on Windows.) I'm painfully aware of some of the breakage GCC occasionally causes (the atomics fall into that — but to be fair ARMv6 is also >10 years ago at this point, unless you're doing embedded, in which case you generally build the whole system anyway and don't care about these breaks.)

Also, just in case it's not clear, glibc has nothing to do with GCC.

xg151mo ago

You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.

eqvinox1mo ago

Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?

1 more reply

j / k navigate · click thread line to collapse

0 comments

eqvinox1mo ago

> https://sourceware.org/bugzilla/show_bug.cgi?id=32653

dlopen and dlmopen no longer make the stack executable if a shared library requires it

The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything.

> __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");

I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?

manwe1501mo ago

Sure, the ABI does not change at all, if you know in advance where the landmines are. Though it does have quite few, especially for a large project with a huge surface area

eqvinox1mo ago

Also, just in case it's not clear, glibc has nothing to do with GCC.

xg151mo ago

eqvinox1mo ago

Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?

1 more reply

j / k navigate · click thread line to collapse