PowerPC Solaris on the RS/6000

The following is a guest post by PA8600/PA-RISC! Thanks for doing this incredible writeup about an ultra rare Unix!

One of the weirdest times in computing was during the mid-90s, when the major RISC
vendors all had their own plans to dominate the consumer market and eventually wipe out
Intel. This was a time that led to overpriced non-x86 systems that intended to wipe out the
PC, Windows NT being ported to non-x86 platforms, PC style hardware paired with RISC
CPUs, Apple putting the processor line from IBM servers into Macs, and Silicon Graphics
designing a game console for Nintendo. While their attempts worked wonders in the
embedded field for MIPS and the AIM alliance, quite a few of these attempts at breaking into
the mainstream were total flops.

Despite this, there were some weird products released during this period that most only assumed existed in tech magazine ads and reviews. One such product was Solaris for PowerPC. Now Solaris has existed on Intel platforms for ages and the Illumos fork has some interesting ports including a DEC Alpha port, but a forgotten official port exists for the PowerPC CPU architecture. Unlike OS/2, it’s complete and has a networking stack. It’s also perhaps one of the weirdest OSes on the PowerPC platform.

  • It’s a little-endian 32-bit PowerPC Unix and possibly the only one running in 32 bit mode. Windows NT and OS/2 (IIRC) were the other 32-bit PowerPC little-endian OSes and Linux is a 64 bit little endian OS.
  • It’s a limited access release, yet feels as polished as a released product.
  • It has a working networking stack.
  • Unlike AIX, it was designed to run on a variety of hardware with room to expand if more PPC hardware was sold. You can throw in a random 3com ISA NIC for example and it will in fact work with it.
  • It shares several things with Solaris for Intel including the installer.

I’m going to demonstrate perhaps the weirdest complete PowerPC OS on fitting hardware: the IBM RS/6000 7020 40p, also known as the Power Series 440 (6015) and by its codename “Sandalfoot”. The system is a PowerPC 601 based machine, featuring the PCI and ISA buses in an LPX style case. This is also one of the few machines that can run it. All screen captures are from a VGA2USB card as emulators cannot run anything but AIX.

What you need to run Solaris PPC

To run Solaris, the system requirements are just like that of Windows NT for PowerPC. You need a PReP machine (PowerPC Reference Platform, not to be confused with the HIV prevention pill or PrEP according to Wikipedia). Now finding a PReP machine is perhaps the hardest part of setting up Solaris for PowerPC and to understand why you need to know a bit about the history of the PowerPC platform.

One of the biggest problems with PowerPC hardware to this day has been the sheer inconsistency of how each machine boots. While Alpha machines had SRM/ARC and SPARC machines had OpenBoot, each vendor had their own way of booting a PowerPC machine despite rolling out standards.

There were essentially two different camps building PowerPC machines, IBM and Apple. IBM’s plans for universal PowerPC machines consisted of industry standard, low cost machines built around a PowerPC CPU, chipset, and lots of supporting components lifted from the PC platform along with PCI and ISA. The CHRP and PReP standards were essentially PCs with PowerPC processors in them. IBM’s plan was that you were going to replace your PC with a PowerPC machine someday. This was cemented by the fact that Windows NT was ported to the PowerPC platform, that OS/2 had an ill-fated port, and that a handful of third party Windows NT PPC machines were sold.

Apple on the other hand wanted to build Macs with PowerPC CPUs. Older Power Macs featured no PCI slots or Open Firmware, only NuBus slots carried over from classic 68k Macs. In fact much of the boot and OS code was emulated 68k code. Later on Apple would lift bits and pieces of things they enjoyed from the PowerPC standards such as Open Firmware, PCI, and even PS/2 and VGA ports on the clones. Apple’s plan was to replace the PC with the Mac, and Mac clones featured Apple style hardware on LPX motherboards. While the PCI clones featured Open Firmware, this version was designed to load the Macintosh Toolbox from ROM while “futureproofing” them by adding in the ability to boot something like Mac OS X/Rhapsody or BeOS.

Despite these similarities Macs were their own computers and were nothing like the IBM systems internally, aside from sharing the same CPU and maybe Open Firmware later on. But even Macs with Open Firmware were incapable of booting from hard disks formatted for IBM systems and vice versa. This is a common problem with installing PowerPC Linux as many installers do not check which machine they’re run on. Furthermore unlike modern day Intel Macs, PPC Macs were designed to only boot operating systems specifically written for them. They were incapable of running any OS solely written for the IBM machines.

The confusion between PPC machines has also caused a forum question to pop up, “how can I install PowerPC Windows on my Mac?” Even today the new OpenPower/PowerNV machines use a different bootloader than IBM’s hardware and completely lack Open Firmware.

Anyhow IBM built several different generations of PowerPC UNIX machines under several brand names including RS/6000, pSeries, and Power. Nearly all of them (aside from the Linux models) will run AIX, and later ones will run IBM i as well. Not just any PowerPC IBM hardware will run the OSes designed for PReP hardware however.

To run these old PReP OSes you’re looking at a very specific set of machines from the 1994-95 period, many with no characteristic diagnostic display most RS/6000 machines have. To run PowerPC Solaris much of the same applies here. You need a RS/6000 40p, or 7248 43p (not the later 140 and 150 with the display). The rare PPC Thinkpads and Personal Computer Power Series machines will run Solaris as well. It’s also compatible with the PowerStack machines from Motorola and one BetaArchive user had luck running it on a VME board. These machines are hard to find and unemulated as of writing, though the firmware files exist for the 40p at least and some efforts have been made in QEMU.

Mine features a PowerPC 601 CPU, 192mb of RAM (the max), a Weitek P9100 video card (branded as the IBM S15 IIRC), and a non-IBM 3com NIC. The 3com NIC has issues with the system as during boot if the NIC is connected to the network the system will refuse to boot fully and will either freeze or BSOD (in NT). The NIC is also not supported on AIX as well, and will eventually need to be replaced.

Curiously, not only is the IBM 40p/7020/6015 not listed in the HCL but the NIC it uses is. It’s well known that the Sandalfoot systems were used for early PReP OS development and it makes sense. Unlike the RS/6000 model 250, the 40p features PCI and ISA busses along with the same 601 CPU early PowerPC machines had. 


To install PowerPC Solaris, you first need to make a boot floppy. This isn’t uncommon with PReP operating systems. PowerPC Windows NT also requires a boot floppy for the ARC loader. The difference here is that there are two boot floppies; one for Motorola machines and one for IBM machines. Even on PowerPC this wasn’t terribly unusual, both the Moto Powerstack and Apple Network Server computers required custom AIX install media as well and Windows NT had specific HALs for each PPC machine.

On the Motorola PowerStack machines you need the same firmware used to install AIX instead of the ARC firmware for NT. On the IBM machines it’s vastly easier, you just need to make the floppy and shove it in. You then press the power switch and you’ll end up dumped to an Open Firmware prompt. As these IBM machines did not have Open Firmware, the bootloader loads Open Firmware from the floppy or hard disk every time you boot the machine. Keep in mind even the system management services are floppy loaded on these machines.

You then run into the first big hurdle to installing the OS, “disk” and “net” are mapped to very specific devices and if the SCSI IDs of these are different it will not boot. If the CD drive is not at ID 3 and the HDD is not at ID 6 the commands will not work. You will need to set an environment variable and tell it to boot from these disks manually for the first install.

Booting the OS is similar to booting it on a Sun, but the installer resembles that of the Intel version. The first thing that happens is you wait for the slow 2 speed CD drive to load the OS as the screen turns Open Firmware white. You will need to set the terminal type, and then then video and mouse input before X will load. The video options are limited to the S3 864/928, the Weitek P9000 and P9100, and Moto’s Cirrus Logic GD5434. Notice how the Power Series 440 (6015)/RS6k 7020 40p is referred to by its codename “Sandalfoot”.

Once you enter this in Solaris will boot load X it does on a Sun or Intel box, and the installer will be exactly the same. This phase is very uneventful as the slow CD drive copies files to the hard disk. I didn’t take a lot of screenshots of this part because you can get the same experience with QEMU or an old SPARCStation. You set the network info, you partition the HDD, you choose what you want, and you sit back as it installs.

Then you’ll be dropped at the Open Firmware bootloader and you’ll enter the right commands to make it boot if “boot disk” doesn’t automatically boot the OS.

The installation is not complete however. The next step is to swap CDs and install the GUI. A default install will drop you at a command line, with the second disk you can install OpenWindows and CDE and get a full working desktop. Login, switch CDs, change to the correct directory, and run the installer.

Once this is done, simply type in reboot and once you login you’ll be at a desktop that looks exactly like a Solaris 2.5.1 install on any other platform with one difference. There is literally zero third party software, and for years there was literally zero way of making software for it. You’re stuck with a stock OS and whatever utilities Solaris 2.5.1 came with. You’ll want to use OpenWindows as well, CDE is vastly slower on the 601 CPU (but not as slow as AIX 4.3 for example). The platform directory also tells you what IBM machines it can run on, and all the RS/6000s are titled PPS. The 6015 is the 40p, the 6040 and 6042 are the ThinkPad models 830 and 850, the 6050/70 are the Personal Computer Power Series variants of the 7248 43p, and the PowerStacks are pretty self-explanatory.

The Compiler Problem (and solutions)

For the longest time Solaris for PowerPC was neglected among those who happened to own a PReP machine for one reason: it lacked a compiler. A compiler is perhaps the most important part of any operating system as it allows one to write code for it. As was the case with UNIX operating systems from the time, the compiler was sold separately. With any UNIX that was widely distributed this wasn’t too much of an issue, as GCC or other third party compilers existed for the platform. Furthermore most compilers for these commercial UNIX operating systems ended up dumped online.

Solaris for PowerPC lacked both of these for ages due to the obscurity and rarity of the port. But in 2018 Tenox dug up the official compiler, yet this remained unnoticed for a while. This led to someone else experimenting with cross compilation on Solaris, and managing to compile PowerPC Solaris software. They then released a port of GCC for Solaris 2.5.1 for PowerPC while posting instructions on how to compile it.

To use GCC for Solaris, you need to unzip the compiler, add it to the path, and then symlink a few files that GCC ends up looking for. This is discussed in the BetaArchive thread about this, but I’ll quote it here.

$ ls -l /opt/ppc-gcc/lib/gcc-lib/powerpcle-sun-solaris2/2.95/
total 13224
-rwxr-xr-x   1 bin      bin      5157747 Feb 16 10:30 cc1
-rwxr-xr-x   1 bin      bin       404074 Feb 16 10:30 collect2
-rwxr-xr-x   1 bin      bin       453525 Feb 16 10:30 cpp
-rw-r--r--   1 bin      bin         1932 Feb 16 10:30 ecrti.o
-rw-r--r--   1 bin      bin         1749 Feb 16 10:30 ecrtn.o
drwxr-xr-x   3 bin      bin         1024 Feb 16 10:29 include
-rw-r--r--   1 bin      bin       673012 Feb 16 10:30 libgcc.a
drwxr-xr-x   2 bin      bin          512 Feb 16 10:30 nof
-rw-r--r--   1 bin      bin         4212 Feb 16 10:30 scrt0.o
-rw-r--r--   1 bin      bin         1360 Feb 16 10:30 scrti.o
-rw-r--r--   1 bin      bin         1104 Feb 16 10:30 scrtn.o
-rw-r--r--   1 bin      bin         7868 Feb 16 10:30 specs
lrwxrwxrwx   1 root     other         24 Feb 22 21:35 values-Xa.o -> /usr/ccs/lib/values-Xa.o
lrwxrwxrwx   1 root     other         24 Feb 22 21:36 values-Xc.o -> /usr/ccs/lib/values-Xc.o
lrwxrwxrwx   1 root     other         24 Feb 22 21:36 values-Xs.o -> /usr/ccs/lib/values-Xs.o
lrwxrwxrwx   1 root     other         24 Feb 22 21:36 values-Xt.o -> /usr/ccs/lib/values-Xt.o
lrwxrwxrwx   1 root     other         26 Feb 22 21:37 values-xpg4.o -> /usr/ccs/lib/values-xpg4.o

Once you do this, you can now compile C code at least with GCC. This means that Solaris for the PowerPC platform now is a usable operating system, aside from the fact it has no precompiled software whatsoever. Even Windows NT for PowerPC has more software for it. Software can now be compiled using GCC or the original compiler, and cross compiled with GCC on a non-PPC box. Using the cross compiler lets you compile more basics for compiling PPC Solaris code as well such as make. In this screenshot you can also see me compiling a basic “endian test” code example to demonstrate the little endianness of the PowerPC port.

The only problem is that there’s going to be little interest until someone makes a PReP machine emulator. PReP hardware is very hard to come by on the used market these days and while in the early 2000s it might have been easy to find something like a specific RS6k, but judging by the eBay listings there were a lot more MCA, CHRP, and even later PReP models (like the 43p-140) than there are early PReP machines in circulation. QEMU can emulate the 40p somewhat, but right now its 40p emulation is less like an actual 40p and more like something to please AIX. It definitely has the novelty of being a “little-endian PowerPC Unix” however.

GCC moved to git!

After all that flap about having moved GCC into GIT I thought it would be worth checking out, you know digging for interesting old artifacts.

I found the ‘start’ back over here on github:

Sadly the ‘initial revisions’ only contain a few files, far from the contents of the ’87 archive.


Not that I would envy anyone crazy enough to do such a thing, I was just hoping someone else would have done a better job than I did.

GCC from ’87 on the 68000

Years ago I found the ‘first’ released version of GCC, and had built it for the VAX. And things were… fun.

While digging around on bitsavers for new and interesting things, I saw some newer stuff from MIT, and stumbled into the GNU directory and rediscovered the early GNU software depot.

And I re-built the early GCC to target the 68000 which I’d imagine primarily was for the SUN target.

simple program

Using a simple program I can run it through the pre-processor, and the compiler to get the following assembly:

assembly from ’87 GCC

Then it’s a matter of running it through the cross assembler, uuencoding it, and sending it to the target.

I used the cross assembler from the AtariST cross ‘project’, to get an object file. I fired up MachTen, pasted my object file to the VM, and uudecoded the object.

And yeah, much to my surprise the object file linked fine, and I got my native EXE.

It’s not much of a cross toolkit, and honestly it’s kind of useless… but I thought it was maybe worth a bare paragraph to show the other available target available for the 1987 release of GCC.

Also on the MIT archive is TRIX, the MIT Unix work alike that almost became the GNU Kernel, until Mach stole their hearts, and basically lead them on a wild goosechase.

I haven’t bothered uploading binaries or patches or anything yet, I don’t know if people are interesting in such a fringe thing……

Congruent (Toolbusters) GCC 2.4.5 for Windows NT

Perhaps one of the more interesting, if not abandoned GCC ports.

It’s from 1994 (although they apparently had earlier), and it’s just enough binutils & gcc to compile stuff for Win32.

I stumbled onto the directory http://www.nic.funet.fi/index/win-nt/gcc/ while looking for the source code to the ‘top’ program, which incidentally can be found here. In hindsight the name ‘top’ is pretty terrible, as looking at the ‘top program for Linux’, well you are going to find all kinds of crap, and surely not top.

The files gnu-bin.tar.Z and gnu-lib.tar.Z contain enough binaries for GCC 2.4.5 C/C++ and ObjectiveC, along with GAS and what purports to be a linker, although I think it just prints the flags to MS Link that you’d need.

And as mentioned in this post, by Juha Inkari, how on earth do you use this thing? Well thankfully in the future we have access to more stuff, so I decided to throw MinGW at it, and see what happens.

I’m using the Linker & LIBC from Fortran PowerStation 1.00 with the linker update.

There is no source diffs, patches, or anything really.

Is this useful? I suspect not. Thanks to RSXNT there is easier ways to get much older versions of GCC… Although I guess it speaks more so to this port using OMF objects.

Congruent Corporation
110 Greene Street
New York City, NY 10012
(212) 431 – 5100
(212) 219 – 1532 (f)

Anyone ever heard of Congruent? Sounds almost Cygnus like.

I think I’m chasing a struct packing issue

i386 breaking on the AASTINKY texture

On the i386 a texture info lump loads up just fine. However on a big endian G5…

OS X 10.2.8 on the G5 on the same AASTINKY

…It clearly has problems. Although notice that the positions and sizes are the same, as they ought to be.

Notice how originx is 24, which should be the width. This code was running with GCC 1.30/1.40 hammered x68000 GCC. Although I have been unable to get the much vaulted gcc-1.30.atari.tar.bz2 to do anything useful, well until tonight, when I found this file: GNU_HEAD.ARC.

That’s right, it’s the gcc-1.23 release headers for GCC on the Atari ST. Now I know other places people have been saying I should use MINT or some GCC8 port. And I wanted something to run on bare TOS, and I cross compiled the simple Infocom interpreter but it just crashes out after a few commands. It’s hardly stable.

3 bombs and an exit under GCC 8.0

Which is just a damned shame, as it was easier to just download someone else’s work.

Anyways, I now can build the old gcc-1.30 libc however… the linker that I’m using that works for GCC 2 links away and it looks like a working program but it doesn’t do anything. I have a feeling the linker drifted in those years between GCC-1.30 and GCC-2.something when it was adapted. Certainly by the time of 2.5.8. So yet more endian ghosts to chase down if I try to adapt that linker.

Cross compiling to the Atari ST

This was a lot harder than it should have been. And not because of gcc or surprisingly ancient binutils.

I didn’t have much to go on, as ancient threads like this, or this end up unanswered or without any good conclusion. I guess it’s not surprising that all the attention is to MiNT & MINIX rather than the native platform. But I was not deterred.

The reason why this was so freaking hard was how so much of key parts of gcc for the ST have been purged and what remains being scattered to the winds. Amazingly the hardest thing to source is the include files. There is a GCC 1.30 file on all the usual GNU mirrors but to save a few kb it has no headers, instead it wants you to reuse the ones from the 1.25 binary distribution. Which is gone. There survives a pl95 binary and source package, but again no includes. Instead I got lucky with all three for pl98. Which has a lot of GCC2 hooks so I cheated on getting the 1.30 hello world by using the 2.5.8 pre-processor.

It’s kind of annoying how all these seemingly tiny files get purged to save a few kb. Just as I can’t for the life of me find the old original GNU libc.

Speaking of files, ZOO has to be the worst compressor ever. Not only is it just overall worse than ZIP, but there are 2 incompatible compression methods, like the introduction of LZD, which any of the good versions of UNZOO can’t deal with. And sure there is zoo210.tar.Z but despite being able to build it on multiple platforms it never does anything useful. All these ancient fileformats sure don’t help anything. And sure there is a MS-DOS version that the MS-DOS Player can run, but get ready for 8.3 filename renaming.

The one good thing that came out of this experience is that since I am building form i386 to 68000 I found that this setup uses the G++ linker which has endian swapping. So maybe I can complete the chain for Mint and MachTen.

I even got the 1987 Infocom interpreter running. Although I don’t know what the deal is, it seems the larger the GCC based program is the higher chance it’ll just crash on exit or force the next program to crash. Building anything native under emulation was an impossibility.

In the same effort, I’ve had the same luck with sozobon. It took way too long to find a working dlibs. I don’t know why people couldn’t either package them together or at least in the same directory. It took far longer just to find the libs… But it was still fun to get that one running as well.

It’s a far more manual process to compile as I have to invoke each stage manually, but at least I’m finally able to get things going.

One of the bigger issues is that I would always find libraries in this olb file format, that the linker from Sozobon wouldn’t recognize. And almost every attempt of trying to build the G++ linker would also fail on. It wasn’t until I was able to get the pl98 include files that I could finally get a linker to actually recognize this … seemingly different for no apparent reason format to actually link. After then I managed to finally find a build of this dlibs that would actually link with Sozobon, which naturally didn’t use olb at all.

So yeah that was an adventure.

I haven’t cleaned it up at all, and really wouldn’t expect anyone else to care, but all my mashed together work (source & binaries!) is here: MinGW-AtariTOS.7z


I started browsing more cd.textfiles.com and amazingly found a ‘home made CD-ROM set’ of Atari software, and buried in the gigabytes of stuff was 4 of the 5 disks of the original GCC-1.23! Namely the source & includes to the first GCC library. I didn’t think this article was going to get any traction, let alone downloads. So many people downloaded the above download.

Anyways I started to put together a better package on sourceforge since it’ll do the multiple GIT’s and nicer downloads.

Download crossAtariST

The default download set is for GCC-1.30, with the headers & lib, along with source. It’s crazy small which just goes for how this old stuff is, and how impact full for losing a few kb.

Also the shell that you use apparently makes a BIG difference. The shell that I was using EmuCON doesn’t show any output from the GCC 1.x libs. However other shells most certainly do. I’ll have to do another update regarding shells/emulation.

Gopher kills the LC

Macintosh LC

The LC isn’t a strong Macintosh.  It is after all, a low cost model.  And what I’m doing isn’t even slightly fair to it.

Since it has a mere 68020 running at a blazing 16Mhz with no 68881 nor any MMU running something like A/UX is simply out of the question.  However MMU less Mac’s can run MachTen.

Although I did make a backup of the disk to find out that this thing had been in Harvard of all places, apparently once belonging to Mark Saroyan.

Although there was nothing even slightly academic or useful on the disk.  I wonder if the software was even pirated as the last owner sure enjoyed all the various SIM games (city/earth/life/ant) it seems more than anything else.

I formatted the massive 50MB SCSI disk, put on a fresh copy of MacOS 7.0.1 along with the network driver and MachTen 2.2.

System 7.0.1

And as far as LC’s go, this one isn’t too bad, it’s loaded up with the maximum 10MB of RAM, although it seems the VRAM is pretty sparse as it’ll only go to 16 colours.  But since we are playing UNIX here, I didn’t see any need for that, and set it to mono.

I thought it’d be fun to install a gopherd server onto this machine, and that is where the fun started.

Granted it’s been a long time since I used a machine with no real L2 cache, let alone running at a whopping 16Mhz, and using a compiler like GCC is just incredibly slow.

So I thought I could just ‘cheat’ the system by taking the source code to GCC-1.42 and tweaking the SUN3-Mach configuration into a SUN2-Mach configuration but keeping it targeting a BSD like OS, along with setting it to compile to a 68020 without a 68881.  Oddly enough getting a cross compiler wasn’t so difficult, but the assembler on the LC, a modified GAS wouldn’t assembler the files. So I went ahead and built a68 from GAS 1.38 and now I can cross assemble from Windows. However I couldn’t get the linker ld from binutils-1.9 working.  I guess it was an endian issue somewhere, but my attempt at byte swapping files it was reading just led to further confusion.  And I figured linking on the target host wouldn’t be the end of the world, as compiling sure feels like it is.

I can’t see like anyone would care, but here it is: 

So fighting the source and in a matter of a 30 minutes of on/off work I had it compiled.  All I needed to do then was FTP the objects to the machine, link and run.   Surprisingly this proved to be pretty simple.

gopherd running!

I managed to get a few pages out of it, and suddenly my telnet sessions dropped.  Looking over at the console and MacOS was busy being MacOS.

error of type 3

And that was that.

I tried another program to cross compile and upload phoon!

phoon cross compiled, natively linked.

It took a while to set the clock to the right year, as my minimal System 7 install doesn’t have the time control panel, and advancing 1 year at a time from 1999 takes time, by advancing the date to New Years Eve every minute 19 times to get us to 2018 with the old date syntax:

date 12312359

Lessons learned?

Obviously if I want to do something like this, I’m going to need a better Macintosh.  Or just not do things like this….

I’m kind of on the fence as to whither 68k Unix is really all that useful in the age of Ghz x86.  

Anyone in need of bash?

I found this post the other day, and thought it was interesting.

Date: 13 Apr 91 18:17:44 GMT
Organization: University of Helsinki
Lines: 18

I've recently ported bash to minix-386 (nice, but takes about 300kB of
RAM). It's been "tested" by me using it all the time (good editing and
history - couldn't live without it any more), but I won't make any
guarantees. If anybody is interested in cdiffs against bash-1.05, please
mail me (I'll post if there is enough interest).

The port definitely needs GCC, and 386-minix. ST-minix will probably
work as well (I've sent it to one ST-minixer), after changeing a #define
LITTLE_ENDIAN to BIG_ENDIAN. If the port already has been done by
someone else - just ignore this message.

		Linus Torvalds		[email protected]

PS. I've hacked the kernel to accept gcc-compiled programs directly
without going through gcc2minix, but I haven't tested it very much yet
(bash works though, so most things probably will). Changes are trivial,
mail me if interested. (And yes - it accepts old minix format too - you
don't have to recompile everything :-)

Naturally it’s about the impending birth of Linux.  First he needed to get GCC running under Minix 386, but I didn’t know at the time that he had patches floating around to allow Minix to directly run the GCC A.OUT format executables.

Scary to think that if Minix had allowed submissions and ‘bloat’ that Linux would have never been.

On the other hand, much like 386BSD the backpressure of having some kind of free BSD/UNIX system which did take in submissions was overwhelming, with the false start of 386BSD going the route of Minix and in that first critical year not pulling in any of the additional patches, while Linux grew by leaps and bounds.  By the time the AT&T vs BSDi lawsuit hit, well the game was already in Linux’s favour, even with it’s already fragmented distro base.

Re-building old GCC distribution tars AKA patching backwards

AKA for everyone but me, who never read the readme.  For some reason I got pointed back to my old GCC 1.27 on MS-DOS article, and wanted to see when the 386 really did first appear, and after a bunch of messing around it was shipped in GCC 1.25

Sat Jul 16 14:18:00 1988 Richard Stallman (rms at sugar-bombs.ai.mit.edu)

* *386*: New files.

So there we are, July 16th 1988!

But looking a the ‘old-releases/gcc-1‘ directory there is no gcc-1.25.tar file! So how to get there from here?  Well the simple answer is to take gcc-1.27, and reverse patch it down using the patches in the patches directory.  The only catch of course is to read prior patches to the reverse to see if any files need to be renamed, otherwise there will be failures… specifically in the file gcc.diff-1.25-1.26

So normally I’ve always patched going up, but with the magical -R flag, you can go backwards!  So taking 1.27 you can go to 1.26 by running

patch -p1 -R < ../gcc.diff-1.26-1.27

And this will take 1.27 and downgrade it to 1.26.  As mentioned above the renames for going from 1.26 to 1.25 needs to be done in reverse:

Before installing these diffs, rename files as follows:

mv typecheck.c c-typeck.c
mv decl.c c-decl.c
mv parse.y c-parse.y
mv parse.h c-parse.h

so do the opposite, and then you can reverse diff.

For anyone who cares I put up the tar files on sourceforge here.