Linux Preparing To Finally Remove Support For The a.out Format

[brad0]

No scripts will be broken. That's some made up bullshit. and there is zero confion to anyone that has more than 5 brain cells to rub together.

[partcyborg]

Sure, the scripts should have been specifying the output name. But my question still remains: "for what?" You are going to break some scripts, you should have a good reason. And I don't really think that confusing a few people for who all of these are true is a good reason:

• They know a.out is a binary format, and not just "the default name gcc writes".
• They know enough to care about the difference between a.out and ELF.
• They have never inspected that file in the last 15 years with the "file" util. They have not once used any ELF tools on it and wondered why their ELF tools were working on an "a.out" binary.
• They have not read the docs on the default output formats.

You said yourself that the scripts shouldn't rely on a.out. I would say the same about tutorials. That's a better way to reduce confusion IMO.

Please correct me if I am wrong, but I am fairly certain that GNU autoconf scripts (linux things you build from source starting with running ./configure) generate a ton of tiny a.out binaries to test for library support. Sure these could be changed, but given the likely tens of thousands of package versions out there, changing it suddenly would break a *lot* of stuff

[bug77]

It will still work.

”./a.out” is simply a name, it is ELF format underlying.

I know that. I was just making some (not very inspired) fun.

[uxmkt]

You're all missing the wood for the trees.
Breaking scripts' expectations that a.out exists after cc ran successfully without arguments isn't the problem.
The problem is breaking user expectations that at most a file by the name of a.out will be overwritten.
“Whaddayamean `cc pony.c` eradicated the unrelated program fish and now my shell is broken?"
(The way I see it, the only way out is to make the -o parameter mandatory.)

[chrisq]

Would the plural of the elf format be elves?

[niner]

No scripts will be broken. That's some made up bullshit. and there is zero confion to anyone that has more than 5 brain cells to rub together.

Yes, well, except those extremely rare Configure scripts of software that uses autoconf for building which is just like, you know, most of free software. But sure, made up bullshit, zero confusion and 5 brain cells, because brad0 of the Phoronix forum knows all about the world of software.

[wagner17]

The libc4 -> libc5 transition when Linux distros switched from a.out to ELF was a few years before '97. Somewhat later came the libc5 -> glibc 2.x transition that we're still using.

I've heard lots of references that libc5 --> libc6 transition was awful. I never heard about the libc4 --> libc5 transition. Do you know if that was as difficult as libc5 --> libc6?

[tytso]

I've heard lots of references that libc5 --> libc6 transition was awful. I never heard about the libc4 --> libc5 transition. Do you know if that was as difficult as libc5 --> libc6?

Libc4 and Libc5 were both based on a fork of glibc version 1. So there wasn't the pain caused by the differences of glibc version 1 (forked for Linux) and glibc version 2. However, how shared libraries for a.out and ELF worked are very different, so it was more interesting from the perspective of developers who needed to learn how to use ELF symbol versioning if they cared about ABI backwards compatibility between successive new versions of shared libraries.

I didn't find it all that painful compared between, say, the backwards incompatible differences between autoconf 2.13 and autoconf 2.50+, but other developers' mileage may vary.

As far as the libc5 --> libc6 transition, I was maintaining e2fsprogs such that it could be compiled on AIX, Solaris, NetBSD, A/UX, Windows, etc., etc., So for old-school programmers who believe that good programs are portable programs, and understood how to write programs that were compatible across different versions of toolchains and C libraries, the libc5 --> libc6 transition was not a big deal. On the other hand, if you're one of the people who believe that all the world's a Linux system running x86, then sure, it could be painful.

[brad0]

Yes, well, except those extremely rare Configure scripts of software that uses autoconf for building which is just like, you know, most of free software. But sure, made up bullshit, zero confusion and 5 brain cells, because brad0 of the Phoronix forum knows all about the world of software.

Showing you don't even have 5 brain cells.

[wagner17]

Libc4 and Libc5 were both based on a fork of glibc version 1. So there wasn't the pain caused by the differences of glibc version 1 (forked for Linux) and glibc version 2. However, how shared libraries for a.out and ELF worked are very different, so it was more interesting from the perspective of developers who needed to learn how to use ELF symbol versioning if they cared about ABI backwards compatibility between successive new versions of shared libraries.

I didn't find it all that painful compared between, say, the backwards incompatible differences between autoconf 2.13 and autoconf 2.50+, but other developers' mileage may vary.

As far as the libc5 --> libc6 transition, I was maintaining e2fsprogs such that it could be compiled on AIX, Solaris, NetBSD, A/UX, Windows, etc., etc., So for old-school programmers who believe that good programs are portable programs, and understood how to write programs that were compatible across different versions of toolchains and C libraries, the libc5 --> libc6 transition was not a big deal. On the other hand, if you're one of the people who believe that all the world's a Linux system running x86, then sure, it could be painful.

So you didn't use libtool back during libc5 --> libc6? This page https://www.physics.drexel.edu/~wkin...d/posts/rpath/ references some brouhaha with libtool and Debian during that time.

What about from the user perspective? I looked at the Debian libc5 to libc6 Mini-HOWTO (https://www.debian.org/releases/hamm...ini-HOWTO.html) and it didn't seem that bad but every time I see libc5 --> libc6 referenced it's talked about like it was some horrible experience. Was the libc4 --> libc5 easy for users?