Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!cory.Berkeley.EDU!wan
From: wan@cory.Berkeley.EDU (Hank S. Wan)
Newsgroups: comp.os.minix
Subject: Re: V1.3 Library Ordering...
Message-ID: <7180@pasteur.Berkeley.EDU>
Date: 8 Nov 88 03:04:02 GMT
Sender: news@pasteur.Berkeley.EDU
Reply-To: wan@cory.Berkeley.EDU (Hank S. Wan)
Organization: University of California, Berkeley
Lines: 40

from <5225@louie.udel.EDU>
>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,

There is a fix to tsort.c that was not applied to the 1.2 to 1.3 files from
bugs.nosc.mil.  Unfortunately, there are actually 2 versions of the fix to
the same problem: <4207@killer.uucp> and <5760@killer.dallas.tx.us>.

See if the change log at the head of your tsort.c contains:

from <4207@killer.uucp>:
>  *	readnode(): s1 & s2 should not keep using - 5/25/88 - mrw
or from <5760@killer.dallas.tx.us>
>  *	stupid error causing overlay of s1 & s2 in readnode - 9/12/88 - mrw

I used the first fix and the above cycle problem went away.
There does exists 1 cycle: catchsig.s and signal.s depending on each other.
Since signal is the one that's usually used, I deleted the
catchsig.s -> signal.s dependency.

2 questions:

1.  There is no provision for the routines in libc.a not to contain any
    cycles.  What does asld do when this happens?  Does it read libc.a
    twice? :-(

2.  As mentioned in the appendix in THE book, some linkers stop reading
    the whole libc.a when it has gathered all the necessary routines.
    What does asld do?  If it does stop reading then we should place the most
    often used routines in libc.a first (which tsort has no way of doing).

One solution to the above 2 problems which also speeds up the linking
process is a bsd-like ranlib that builds an index at the beginning of
an archive file.  One would need to modify asld to do this.  Is asld,
just like the compiler, not public domain?  If so is anyone working on
a public domain version?

-Hank Wan
 wan@cory.berkeley.edu