Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!tut.cis.ohio-state.edu!rutgers!njin!princeton!udel!mmdf From: 75008378%VAX2.NIHED.IE@cunyvm.cuny.edu Newsgroups: comp.os.minix Subject: V1.3 Library Ordering... Message-ID: <5225@louie.udel.EDU> Date: 7 Nov 88 10:06:41 GMT Sender: mmdf@udel.EDU Lines: 54 Here's a funny thing: I'm finally trying to get V1.3 running, and the first job, naturally, to to get a clean libc.a. I had a couple of miscellaneous problems (fgetc/fputc multiply defined because getc.c/putc.s both #include stdio.c which promptly redefines getc/putc to fgetc/fputc...) but all in all, everything compiled very nicely. So now I use lorder/tsort to get a good ordering. Some problems getting lorder to work (too many files to feed in on the command line, in 1.2 at least, and building a libc.a and letting lorder extract the files fails cause libupack doesn't handle pipes too well - again in 1.2 at least; but a little hacking of lorder fixed that), but I eventually got it going and then tsort decided there was a cycle in the ordering. tsort didn't actually tell me which modules were (allegedly) involved, but a look at the tsort code, and some more hacking, seemed to show that there were just two fishy modules, and they would be the last ones in the tsort output. Another slight detour to split up the tsort output into separate lines so I could actually *see* what was at the end (who says "well behaved" programs wouldn't benefit from auto line wrap???) and the suspects turn out to be rand.s and something else (I can't remember the latter, but it doesn't matter too much - I didn't find anything else wrong with it). A quick gander at the lorder output, grepping for rand.s, shows the suspicious fact that there are two identical lines showing uniqport.s depending on rand.s. Delete one of these and, hey presto, tsort is happy, and the ordering looks sensible (at least rand.s isn't at the end anymore...). My question is this: *should* lorder/tsort behave like this? The only reason I can see for the duplicate entry in the lorder output is that uniqport separately references two different functions in rand - but that hardly seems a reason for duplicating the entry? If nayone wants to try and reproduce this, just run lorder on uniqport.s and rand.s alone: this should do it, if my sources are close enough to the genuine V1.3 sources (I can't quite vouch for this: my V1.3 sources are mainly courtesy of Richard Hesketh - thanks again Richard - and, of course, my versions of lorder and tsort were somewhat mutilated to make them run under my antique V1.2). This isn't actually holding me up anymore, but I'd still be interested in hearing any comments/explanations... [PS: Der Tynan: sorry for the delay - you *did* get thru to me once, and I quote: (To: amid!decwrl!ucbvax!cunyvm.cuny.edu!75008378%vax2.nihed.ie) but, for the life of me I couldn't get back to you, no matter what variation I seemed to try.... thanks anyway for trying.] Barry McMullin, NIHED, Dublin, IRELAND.