75008378%VAX2.NIHED.IE@cunyvm.cuny.edu (11/16/88)
Havn't had much time for the 1.3 upgrade, but I finally got a clean library together (I think). Thanks for the netland comments: my conclusions are detailed below: Hank Wan <wan@cory.berkeley.edu> wrote: >There is a fix to tsort.c that was not applied to the 1.2 to 1.3 files from >bugs.nosc.mil... Thanks for the tip; unfortunately I don't have convenient access to a good Minix archive, but the hint you gave was enoungh for me to figure out and fix the problem. >There does exists 1 cycle: catchsig.s and signal.s depending on each other. Strangely I hadn't found this; the reason was that several of my relevant .s files didn't have required .define xxx (whatever global symbols are defined within) at the top. I must have missed something along the way in the postings. Once I fixed this, the catchsig.s <-> signal.s cycle was uncovered. >Since signal is the one that's usually used, I deleted the >catchsig.s -> signal.s dependency. On this, Frank Wortner <frank@MORGAN.COM> comments: >Perhaps the problem Hank encounters here implies that signal.s and catchsig.s >should actually be one source file. Yes but: signal is implemented in C, catchsig in assembler, so combining both is a little inconvenient. My strategy was to isolate one of the dependencies in a new file - specifically, I moved the *definition* of vectab into a new file (vectab.c). signal.c still needs a *declaration* (extern) of course. This worked fine for this particular case, and allowed lorder/tsort to come up with a completely clean ordering. Of course, I havn't built the rest of the system yet, so who knows if it will actually work! Stay tuned... Barry McMullin, NIHED, Dublin, IRELAND. <MCMULLINB@VAX2.NIHED.IE>