ma, 2005-05-09 kello 14:39 -0700, Thomas Bushnell BSG kirjoitti: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > You asked why the GNU linker, which does not need to be 'ls' and does > > not need to look at the list of files in any directory, scaled well > > with the size of the directory. That's the question I answered. > > How does ld determine that -latoheun will fail, other than by listing > the directory O(n)? How does ld find -lfoo, without searching through, > on average, half the entries?
I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than "lib%s.a", but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. I suspect this is what Daniel tried to say: that filename lookups aren't O(n) anymore. This means that the performance reason for keeping /usr/lib small is gone. This, of course, has no bearing on whether /usr/libexec should exist or not for other reasons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]