ast@cs.vu.nl (Andy Tanenbaum) (11/26/88)
Every couple of weeks somebody asks me what the order of the files is in /lib/libc.a. Here is my ordering: Andy Tanenbaum (ast@cs.vu.nl) uniqport.s getpwent.s qsort.s popen.s termcap.s scanf.s system.s fgets.s fprintf.s puts.s fputs.s fread.s freopen.s fclose.s fopen.s fseek.s ftell.s fwrite.s gets.s fgetc.s printdat.s setbuf.s ctime.s fdopen.s getgrent.s sprintf.s doprintf.s fputc.s ungetc.s strcmp.s access.s chdir.s chmod.s chown.s chroot.s creat.s dup.s dup2.s exec.s exit.s cleanup.s fflush.s fork.s isatty.s fstat.s getegid.s getenv.s geteuid.s getgid.s getpass.s close.s getuid.s gtty.s stty.s ioctl.s abort.s kill.s link.s lseek.s malloc.s brk.s brk2.s brksize.s mknod.s mktemp.s getpid.s mount.s open.s perror.s pipe.s prints.s read.s setgid.s setuid.s sleep.s alarm.s pause.s signal.s catchsig.s stat.s stime.s strcat.s strcpy.s strlen.s strncat.s strncmp.s strncpy.s sync.s time.s times.s umask.s umount.s unlink.s utime.s wait.s stderr.s write.s amoeba.s syslib.s call.s atoi.s message.s sendrec.s printk.s itoa.s stb.s abs.s atol.s ctype.s index.s bcopy.s getutil.s rand.s rindex.s setjmp.s portio.s adi.s and.s cii.s cms.s cmu4.s com.s csa2.s csb2.s cuu.s _dup.s dvi4.s dvu4.s exg.s fakfp.s gto.s iaar.s ilar.s inn.s ior.s isar.s lar2.s loi.s mli4.s mon.s nop.s rck.s rmi4.s rmu4.s sar2.s sbi.s set.s sti.s strhp.s xor.s error.s unknown.s fat.s trp.s stop.s ret6.s ret8.s lfr6.s lfr8.s retarea.s blm.s vars.s return.s cmi4.s crypt.s
dtynan@sultra.UUCP (Der Tynan) (11/30/88)
In article <1705@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > > Every couple of weeks somebody asks me what the order of the files is in > /lib/libc.a. Here is my ordering: > Andy Tanenbaum (ast@cs.vu.nl) [Ordering deleted -- go see the original posting :-] What I have ended up doing, is writing a simple shell script to read the file 'order', split it up (in the same way Art Zemon did), and generate a NEW libc from the .s files. The original 'run' script has given me endless problems, for example, if a function fails to compile, it's impossible to just continue. I have found that use of 'run' usually will end up destroying my copy of libc.a and because it doesn't keep a copy around, I have to go to backup tapes. Why is it, that not all the routines are actually in the source directory, meaning that 'run' must go to /usr/lib/libc.a to get the remaining. I made a list of all the files not included (xor.s, cmu4.s, etc), and put copies in IBM_PC, so that I can basically build a library from scratch. I have finally gotten lorder and tsort to work, so I no longer need to try and find up-to-date orderings, when I add new routines (like ndir, or getopt). The only problem is in the looping of 'catchsig.s' and 'signal.s'. For this reason, I use the following; lorder *.s >order.tmp Then, edit order.tmp, removing the line that has; catchsig.s signal.s Finally, run tsort order.tmp >order ; rm order.tmp This works just fine, and means I never have to worry about library ordering again. If anyone wants more info, just send me e-mail. BTW; Des Young tells me that most of those 'strange' files (cmu4.s etc) are no longer needed. Is this the case? I am still including them. - 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? ---