clang looking all over for linux libs [9.2 PRERELEASE]

[Kurt Lidl]

I noticed this issue this morning, while looking at a unrelated
compilation failure. I was using clang on an amd64 machine,
running a system that corresponds closely to r253388.
There are some local changes, but nothing with regards to the
toolchain, except for removing GCC via the WITHOUT_GCC flag in src.conf.

lidl at nine0-135: cat hello.c
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("Hello world\n");
	return 0;
}
lidl at nine0-136: ktrace -i clang -c hello.c
lidl at nine0-137: kdump |less
[...]
  74004 clang    CALL 
open(0x7fffffffbf00,0x120004<O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>,<unused>0x1d)
  74004 clang    NAMI  "/usr/lib/gcc/x86_64-linux-gnu"
  74004 clang    RET   open -1 errno 2 No such file or directory
  74004 clang    CALL 
open(0x7fffffffbf00,0x120004<O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>,<unused>0x2e)
  74004 clang    NAMI  "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
  74004 clang    RET   open -1 errno 2 No such file or directory

My question is:  Why is the system compiler looking for all these
directories that do not exist?

lidl at nine0-144: kdump |egrep -e NAMI -e /usr/lib | awk '{print $4}'
[...]
"/usr/lib/gcc/x86_64-linux-gnu"
"/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
"/usr/lib/x86_64-linux-gnu"
"/usr/lib/gcc/x86_64-unknown-linux-gnu"
"/usr/lib/x86_64-unknown-linux-gnu/gcc/x86_64-unknown-linux-gnu"
"/usr/lib/x86_64-unknown-linux-gnu"
"/usr/lib/gcc/x86_64-pc-linux-gnu"
"/usr/lib/x86_64-pc-linux-gnu/gcc/x86_64-pc-linux-gnu"
"/usr/lib/x86_64-pc-linux-gnu"
"/usr/lib/gcc/x86_64-redhat-linux6E"
"/usr/lib/x86_64-redhat-linux6E/gcc/x86_64-redhat-linux6E"
"/usr/lib/x86_64-redhat-linux6E"
"/usr/lib/gcc/x86_64-redhat-linux"
"/usr/lib/x86_64-redhat-linux/gcc/x86_64-redhat-linux"
"/usr/lib/x86_64-redhat-linux"
"/usr/lib/gcc/x86_64-suse-linux"
"/usr/lib/x86_64-suse-linux/gcc/x86_64-suse-linux"
"/usr/lib/x86_64-suse-linux"
"/usr/lib/gcc/x86_64-manbo-linux-gnu"
"/usr/lib/x86_64-manbo-linux-gnu/gcc/x86_64-manbo-linux-gnu"
"/usr/lib/x86_64-manbo-linux-gnu"
"/usr/lib/gcc/x86_64-linux-gnu"
"/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
"/usr/lib/x86_64-linux-gnu"
"/usr/lib/gcc/x86_64-slackware-linux"
"/usr/lib/x86_64-slackware-linux/gcc/x86_64-slackware-linux"
"/usr/lib/x86_64-slackware-linux"
"/usr/lib/gcc/x86_64-unknown-freebsd9.2"
"/usr/lib/x86_64-unknown-freebsd9.2/gcc/x86_64-unknown-freebsd9.2"
"/usr/lib/x86_64-unknown-freebsd9.2"

It's actually a lot worse than this -- it also looks in /usr/lib32 for
a different set of directories, and then again in /usr/lib
for that diffferent set of libraries, and then in /usr/bin/../lib
for the original set of directories and then again(!) in
/usr/bin/../lib32 and /usr/bin/../lib for the second set of directories.

I would think, that as the configured system compiler, it wouldn't
bother looking around for a bunch of stuff that it isn't going to
find...  Sure, the data is in the buffer cache after the first run,
but how about just not making several hundred useless system calls
for each invocation of the compiler?

All this seems to come from:
	/usr/src/contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp

Is there something that can done to make this work better?

-Kurt