jnall%FSU.BITNET@CORNELLC.CIT.CORNELL.EDU (John Nall 904-644-5241) (11/29/88)
From the several people who answered my query regarding the D1.2-1.3.tar.Z file, there were several who said that they had successfully upgraded to Minix 1.3. Unfortunately, I don't remember their names (or I would just e-mail directly, rather than broadcasting to the net). The following is a follow-up question: I've successfully moved the file, and gotten the various parts onto my AT under Minix. Now comes the part of compiling the source to make the new 1.3 version, and I've hit a couple of snags that I can't solve. I suspect they're related: (1) When compiling the new minix/commands subdirectory (that is, doing a make on all of it) I have several unsatisfied externals. They are _clean (in animals.c), _fdopen and _exit (in at), and a few more. I previously did a "run" on minix/lib and moved the resulting lib.ca to /usr/lib. (I meant "resulting libc.a...). But I didn't reorder the library beyond what run does. Does that have to be done? (2) Many, many of the minix/commands are getting an error which says "no space on root device (RAM disk) and the make aborts. This includes tsort.c, which is why I didn't run it on libc.a. How does one get around this? (3) minix/mm compiles ok. minix/fs gets an unsatisfied external (something named _sys_kil)?? minix/kernel gets unsatisfied externals of _port_in and _port_out. SO...any suggestions on the unsatisfied externals and no room on RAM disk? I spent fifteen years as a systems programmer (on Control Data systems) and don't mind the learning experience, but it takes a while to get all the details down. Thanks John Nall Department of Computer Science Florida State University (jnall@fsu)
jds@mimsy.UUCP (James da Silva) (11/30/88)
In article <5718@louie.udel.EDU> jnall%FSU.BITNET@CORNELLC.CIT.CORNELL.EDU (John Nall 904-644-5241) writes: > >SO...any suggestions on the unsatisfied externals and no room on RAM disk? >I spent fifteen years as a systems programmer (on Control Data systems) >and don't mind the learning experience, but it takes a while to get >all the details down. I think all your external reference problems stem from improper ordering of libc.a. Andy Tanenbaum just posted the ordering he uses, so if you use that you should be ok. lib/run was a neat hack at the time it was posted, but isn't adequate for any real work. Getting the library right is probably the biggest pain for people working with Minix; except, of course, for those people who have to wrestle with hardware compatibility problems (ok, everyone; sit down already! :-) As for the lack of room on the RAM disk, add '-T.' to the CFLAGS line in the commands makefile. This tells the compiler to use the current directory for temporary files. In fact, you're better off not even using the commands makefile. Just write a shell script something like this: for i in $* do j=`basename $i .c` echo $i cc -T. -Di8088 -o bin/$j $i chmem =3072 bin/$j >/dev/null done That was off the top of my head, so it may not be exactly right. This is faster than using make because without make in memory, there's enough room to run the cpp and the first compiler pass in parallel, with a pipe. Make needs to give cc the '-F' flag, which instructs cc to run the passes one at a time, using a temporary file. Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
dtynan@sultra.UUCP (Der Tynan) (11/30/88)
In article <5718@louie.udel.EDU>, jnall%FSU.BITNET@CORNELLC.CIT.CORNELL.EDU (John Nall 904-644-5241) writes: > > They are _clean (in animals.c), _fdopen and _exit (in at), and a few more. > I previously did a "run" on minix/lib and moved the resulting libc.a > to /usr/lib. But I didn't reorder the > library beyond what run does. Does that have to be done? In a word. Yes! Nothing against Art Zemon's nice piece of code, but unfortunately, it is just a stopgap until you can use lorder and tsort. Of course, it's catch-22 time, because if you don't have a good library, you can't make lorder. Either hand-generate the library using ASTs posted 'order', or use my previous posting, to get 'lorder' to work. > (2) Many, many of the minix/commands are getting an error which > says "no space on root device (RAM disk) and the make aborts. This > includes tsort.c, which is why I didn't run it on libc.a. How does one > get around this? Either do what I did (remove the RAMDISK), or clean out everything but the nonessential commands from /bin, /lib, /etc and all the other places. Of course, don't forget to put them back afterwards :-) As a quick check, run df /dev/ram to see just how bad it is. Then, go from there. > (3) minix/mm compiles ok. minix/fs gets an unsatisfied external > (something named _sys_kil)?? minix/kernel gets unsatisfied externals > of _port_in and _port_out. > > John Nall The first problem is most likely due to your bad library. The second, is because AST *removed* both those functions from the 1.3c stuff. The cdiff files actually pulled out the functions. Since then, Andy has posted a file called portio.s which has the appropriate routines. Other than that, go back to your 1.2 disks, and pull them out of klib88.s (I think that's where they are). Of course, if you use the peephole optimizer posted some time ago, it replaces all calls to _port_in and _port_out, with inline code, which is a nifty idea. Sometime, when I get a chance (Hah!), I'd like to implement that optimizer... - Der -- dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!Tynan.COM!dtynan --- If the Law is for the People, then why do we need Lawyers? ---