Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dasein
    replied
    I suppose they could always pull it out in 5.20/5.21 after checking what the actual possible breaks it could cause with the upcoming releases

    The a.out/DLL shared libraries seem interesting πŸΏπŸ‘€

    Quick question though, how would we request a short delay of 1 or 2 releases if we wanted to? πŸ€”
    I'm not complaining, merely a suggestion
    Last edited by Dasein; 09 April 2022, 12:31 PM. Reason: Accidentally typed wrong versions without checking properly

    Leave a comment:


  • SteamPunker
    replied
    But... Doesn't the removal of a.out support technically break userspace?

    Leave a comment:


  • tytso
    replied
    Originally posted by wagner17 View Post

    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.
    Nope, and I *still* don't use libtool. Libtool, as far as I'm concern, only slows down compile times, and is an unmitigated disaster in terms of the developer trying to understand what the !%[email protected]?! is going on. For example of how to portably support shared libraries without using libtool, please see:An example of how a library Makefile which uses these makefile fragments can be found here.

    The makefile fragment for building a.out/DLL shared libraries has long since been removed, since the toolchain to make sure things would still work is long gone. Similarly, I stopped supporting AIX because I don't have easy access to AIX systems any more.

    (BTW, I also think automake is a mess, and I don't use it for any projects which I maintain. The vast amount of complexity that it adds is just not worth it in terms of the marginal benefits which it brings.)

    Leave a comment:


  • Bigon
    replied
    Originally posted by caligula View Post
    I guess this is different, but many C tutorials introduce the concept of 'a.out' executable to save some typing when compiling stuff:

    $ echo "#include..." > hello.c
    $ gcc hello.c
    $ ./a.out

    Imagine the horror if you had to write this instead:

    $ gcc hello.c -o hello
    $ ./hello

    Requires 9 characters more.
    Code:
    make hello

    Leave a comment:


  • smitty3268
    replied
    Originally posted by shmerl View Post
    It is still confusing that a.out is an elf. If you like misleading mess, then yeah, no need to fix it. But I think it's just an inertia thinking.
    Confusing to who?

    Who even knows that a.out is a file format?

    And yet doesn't know that ELF is the default for 30 years? Seems very likely the # of people confused by this is 0.

    Leave a comment:


  • s_j_newbury
    replied
    Originally posted by tytso View Post

    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.
    I started off using Linux with ipfw to share my modem over a 10base2 ethernet network to my brand new Acorn RiscPC! Fun days! I remember it, from a user perspective, I was pretty new to Linux at the time and my software development was solely on Acorn RISC OS in those days. I went from a Slackware 2.x release to what must have been Red Hat 3.0.3, according to Wikipedia, I remember it had a 1.2.x kernel. Since I changed distributions, it wasn't really an issue, but I was aware of it, probably mostly due to the introduction of shared libraries. In those days, you pretty much used what came with your distribution, maybe compiled some things from source, so compatibility wasn't such a big issue.

    Leave a comment:


  • cjcox
    replied
    Off topic, but if you think libc "this or that" to libc "next" was painful, back when DEC Alpha was first coming out they repeatedly changed their binary exec format. You would come in one day to discover all your executables were simply "data" now. Fun times.

    Leave a comment:


  • wagner17
    replied
    Originally posted by tytso View Post

    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?

    Leave a comment:


  • brad0
    replied
    Originally posted by niner View Post
    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.

    Leave a comment:


  • tytso
    replied
    Originally posted by wagner17 View Post

    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.

    Leave a comment:

Working...
X