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.
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.
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
UPDATE
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.
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.
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.
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.
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.
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:
So as promised, a while back I had built a GCC 2.7.2.3 / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME. Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.
Why not use a more up to date version of both GCC/Binutils? Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too. And it was easier to just get the older tool chain working.
It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.
Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.
Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable. And the best part is checking via DOSBox, it runs, with sound!
MAME 0.1 on DOSBox PACMAN hiding
Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.
Got this fun one in dwarf.c (and probably many others) while building an ELF toolchain from Linux to run on Windows to target.. Linux. Anyways I think this is a symptom of Canadian Cross compilers.
So a little digging and ___eprintf turns out to be from the assert.h as macros for assert depend on this being in libgcc.a .. And yeah, MinGW uses something else. So just copy the assert.h from MinGW, and re-build and away it works.
D:\elfgcc\bin>cc1
int main(){printf("hi!\n");return 0;}
.file "stdin"
.version "01.01"
gcc2_compiled.:
main.section .rodata
.LC0:
.string "hi!\n"
.text
.align 4
.globl main
.type main,@function
main:
pushl %ebp
movl %esp,%ebp
pushl $.LC0
call printf
addl $4,%esp
xorl %eax,%eax
jmp .L1
.align 4
.L1:
leave
ret
.Lfe1:
.size main,.Lfe1-main
^Z
.ident "GCC: (GNU) 2.7.2.3"
time in parse: 1.155000
time in integration: 0.000000
time in jump: 0.000000
time in cse: 0.000000
time in loop: 0.000000
time in cse2: 0.000000
time in flow: 0.000000
time in combine: 0.000000
time in sched: 0.000000
time in local-alloc: 0.000000
time in global-alloc: 0.000000
time in sched2: 0.000000
time in dbranch: 0.000000
time in shorten-branch: 0.000000
time in stack-reg: 0.000000
time in final: 0.000000
time in varconst: 0.000000
time in symout: 0.000000
time in dump: 0.000000
Sure I can cross compile Linux, but what about 386BSD? This had long been a thorn in my side, as the GCC/Binutil toolchain that is used in this early era is not GNU pure, they had been modified in all kinds of ways. One of which was a builtin memcpy that doesn’t work the same as a normal memcpy, and the other being that the C compiler & pre-processor rely in YACC to build the tokens. I had been using bison before, however even though bison didn’t generate any errors it build the compiler wrong enough that the majority of the kernel wouldn’t compile.
As it stands right now, the only things that do not compile is locore
to post process the kernel, symorder is used along with dbsym, although neither do any processing to the kernel file itself, so they aren’t needed to get a working system.
386BSD Release 0.1 by William and Lynne Jolitz.
Copyright (c) 1989,1990,1991,1992 William F. Jolitz. All rights reserved.
Based in part on work by the 386BSD User Community and the
BSD Networking Software, Release 2 by UCB EECS Department.
386BSD 0.1.2018 (GENERICISA) 02/02/18 15:01
Other than that, yeah it’s great, compile a kernel in under 15 seconds.
Anyone that cares, the initial release is here:Â 386bsd01.7z
