deo@eecs.cs.pdx.edu (Steven Furber) (11/10/90)
Several people have asked for tips on getting GCC to work for MacMinx. The following should be more than enough information to do so. I would like to thank the people that gave me the information needed to get GCC up and running, and especially Jwahar R. Bammi for porting it to ST Minix. I have mainly concentrated on Minix itself, and not using ftp. Let me know if you have any problems with this and I will update it. I have not tested this-- I wrote it from memory. I ftp'd all of the GCC files from atari.archive.umich.edu. The directory is atari/gnustuff/minix. The files you want are gccbin.tar.Z, gcclib.tar.Z, and include.tar.Z. (Note: the extensions of the file names MAY not be the exact same, but from the above should be close enough to get a match.) Once you have located these files, MAKE SURE that you are in binary mode. Once you have all of the files on your local site, uncompress them and then recompress them with '-b 13' to make SURE that they are 13 bit compressed instead of 16; I do not know for sure how they are stored, but I do not like wasting all of my time moving 2+ megs of files. Next transfer them. I wanted to transfer them to my MacOS filesystem instead of Minix because (no offense) Kermit is just too slow. What I use is Zterm 0.90, which is about as fast as it gets. Once all of your files are downloaded, the real fun begins. Grab a sixpack, because this will take some time. Boot MacMinix. Time for a decisions-- GCC takes over 1.6mg when it's uncompressed and untar'd. You're going to want to keep compies of the original files around, too, so there's around 3mg of space in the end. Since these files will be going into a various directories under /usr/local (you create ../local)-- and it MUST be /usr/local, you need to decide whether you want to create and mount a file- system or simply jam all of this onto the current filesystem. I made a 10mg filesystem and mounted it on /usr/local. (See 5.7.4 in the documentation for information on making filesystems.) Either way, make sure that you have the following directories: /usr/local /usr/local/lib /usr/local/gcc-include Find some directory for placing the files you just downloaded; it really doesn't matter..I have a /u/gnu directory for all of the GNU stuff I grabbed. For each of the files we'll want to bring them in using 'macread'. (If you forgot the filenames, use 'macfile drive:path..' to take a look at what they are; where path.. is the directory path.) My files were in slave:Zmodem, and this is what I typed: macread slave:Zmodem:gccbin.tar.Z > gccbin.tar.Z macread slave:Zmodem:gcclib.tar.Z > gcclib.tar.Z macread slave:Zmodem:include.tar.Z > include.tar.Z While you could pipe the output from 'macread' into 'uncompress', chances are that you will run into memory problems. Besides, you'll want to keep the compressed files around. When you've done all of this, 'decompress' them all. If nothing else is in the directory, just use: decompress * Next the fun part begins. You'll want to do the following, only using your directory instead of /u/gnu: cd /usr/local/lib tar xvf /u/gnu/gccbin.tar tar xvf /u/gnu/gcclib.tar cd /usr/local/gcc-include tar xvf /u/gnu/include.tar Now that all of the files are untar'd, it's time to make sure they have enough memory. The 'cmem' file may work for others, but it doesn't give enough space for gcc-cc1. To make sure we have enough memory, do the following: cd /usr/local/lib chmod +x cmem chmem =1500000 gcc-cc1 [* see note *] mv gcc /usr/bin/. This will change the memory allocations and move gcc to /usr/bin. NOTE: gcc-cc1 takes a lot of memory to run. I have 4mg of RAM in my machine and I have 2000000 bytes (2mg) allocated for it. 1.5mg will probably suffice. You should now be ready to use GCC. I have not tried rebuilding Minix with GCC yet, nor do I know if it will work on a non-ST machine. --- Steven Furber, reliably steven@m2xenix.psg.com
ladd@cbnewsc.att.com (david.ladd) (11/14/90)
In article <627@pdxgate.UUCP>, deo@eecs.cs.pdx.edu (Steven Furber) writes: [ excellent description of GCC install deleted ] > > You should now be ready to use GCC. I have not tried rebuilding Minix with > GCC yet, nor do I know if it will work on a non-ST machine. I'm still having problems getting stdio to recognize EOF. For instance, .. x = read(0, buf, 1024); write(1,buf,x); .. works, but .. while( (c = getchar()) != EOF ) putchar(c); .. fails to stop at the end of the file. I've tried to re-build libc32.a from atari.archive.umich.edu:/atari/gnustuff/minix/libsrc.tar.Z but I'm having trouble with actually building the archive from the .o's PS: I think one would need to get the kernel from the FTP site and then integrate the diffs to be able to compile it with GCC. Any volunteers??
steven@m2xenix.psg.com (Steven Furber) (11/14/90)
In <1990Nov13.165207.5755@cbnewsc.att.com> ladd@cbnewsc.att.com (david.ladd) writes: >In article <627@pdxgate.UUCP>, deo@eecs.cs.pdx.edu (Steven Furber) writes: >[ excellent description of GCC install deleted ] Thanks. I was a bit worried that the install wouldn't work, but I see you hit on some problems I too am finding (with the help of someone else pointing a couple more out to me...) >I'm still having problems getting stdio to recognize EOF. For >instance, > .. > x = read(0, buf, 1024); > write(1,buf,x); > .. >works, but > .. > while( (c = getchar()) != EOF ) > putchar(c); > .. >fails to stop at the end of the file. I can't help you with this. The lib[32]c.a file seems to have quite a few problems. I was recently told it was for Minix 1.1 or 1.3, and not for a current release. This might be part of the problem (sorry, I'm pretty new to the more brain busting parts of using computers). >I've tried to re-build libc32.a from >atari.archive.umich.edu:/atari/gnustuff/minix/libsrc.tar.Z >but I'm having trouble with actually building the archive from >the .o's You'll need to archive them with GNU's ar, not the Minix ar. Someone recently sent me mail saying they either had the sources or had the sources and ar running. Even if you do recompile all of the libraries, you need to figure out what to do with the MacMINIX system specific stuff (ie: header files). I ran into a problem when using memcpy(..). It turns out the library knows memccpy(..), yet the header file specified memcpy(..). Before I realized that it wanted memccpy(..) something I did to fix it was to compile /usr/src/lib/ansi/memcpy.c with GCC and then link it into my file. It worked, and it may work for other problems. GCC also has problems with stdout being used with fprintf, and I think printf too. I know I had problems when trying something someone else suggested. Right now I'm only using GCC when I've got something that requires ANSI C. Until we can get it up and running for the Mac and MacMinix 1.5, it's going to need tobe handled with extreme care.
ladd@cbnewsc.att.com (david.ladd) (11/19/90)
In article <1990Nov14.021835.5614@m2xenix.psg.com>, steven@m2xenix.psg.com (Steven Furber) writes: > In <1990Nov13.165207.5755@cbnewsc.att.com> I write: > >I'm still having problems getting stdio to recognize EOF. > > I can't help you with this. The lib[32]c.a file seems to have quite a > few problems. I was recently told it was for Minix 1.1 or 1.3, and not > for a current release. This might be part of the problem (sorry, I'm > pretty new to the more brain busting parts of using computers). > Ah, yes, the library Ok, here's the state of GCC/MacMinix as I know it. - the include files don't match the binary of the library (include files use FILE _iob[], binary lib uses FILE *_iop) - My stdio problems were fixed by compiling the library from source. But, read on. > > You'll need to archive them with GNU's ar, not the Minix ar. True, but the binary gcc-ar in gccbin.tar.Z suffers from being compiled with the headers and libs supplied. I had problems with gcc-ar, so (deja vu) I grabbed the sources, re-compiled, and got the same results. Armed with source, I was able to discover that gcc-ar failed only when it tried to open a file in O_CREAT mode. Guess what... The fcntl.h in gcc-include doesn't match the native MacMinix one. Ok, so I fixed that. Then it worked, but failed to "rename" the file. Sure enuf, rename is not a true system call, but a wrapper around link and unlink, and a broken one at that. It turns out that it stats the two files to be renamed and if they're on the SAME device, it fails the call ?! After these adventures, I was able to re-build libc32.a from source, and everything seems to be working now. I'll look into the lib src some more and hopefully post diffs when the dust settles. > Even if you do recompile all of the libraries, > you need to figure out what to do with the MacMINIX system specific > stuff (ie: header files). Well, massaging the kernel into a gnu-compilable state will be a major chore. Anyone looked at the atari kernel at our fav. archive site? > Right now I'm only using GCC when I've got something that requires ANSI > C. Until we can get it up and running for the Mac and MacMinix 1.5, > it's going to need tobe handled with extreme care. Well, define "for the mac." I think it's pretty close right now as a pure minix/user-mode compiler. It's not clear that one would ever want to compile MacBoot with gcc, or any other mac application. Besides, since we Macophiles are able to use all the atari binaries (Thanks Joe P/bammi), it seems like we should try to improve generic minix for the 68k to return the favor.
archetyp@uxh.cso.uiuc.edu (Joseph R Pickert) (11/20/90)
The include files in /usr/include/mac should be ok with either a 16 or 32 bit compiler, since they were intended to work with both. Regarding compiling macboot/kernel with a 32 bit compiler: Since the include files should be ok and since there are prototype defs for the Mac OS calls in them that gcc can use, it should be able to point out most of the potential problems. I can supply a set of /usr/src/lib/mac/*/*.s that work for a 32 bit/gas syntax compiler. If you want them let me know. Joe Pickert