Yes, this is because the FreeBSD driver toolchain shares the same
infrastructure with Linux. So we stat ~200 linux dirs :(
This rys.vlakno.cz/~rdivacky/freebsd-driver.patch proof of concept
patch fixes it by unsharing FreeBSD from Linux but I am not
convinced it's worth it.
It should also be possible to only stat those libs when -m32/-m64
is specified. That would be the preferred solution.
Roman
On Wed, Jul 17, 2013 at 04:13:41PM -0400, Kurt Lidl wrote:
>
> 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@nine0-135: cat hello.c
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> printf("Hello world\n");
> return 0;
> }
> lidl@nine0-136: ktrace -i clang -c hello.c
> lidl@nine0-137: kdump |less
> [...]
> 74004 clangCALL
> open(0x7fffbf00,0x120004,0x1d)
> 74004 clangNAMI "/usr/lib/gcc/x86_64-linux-gnu"
> 74004 clangRET open -1 errno 2 No such file or directory
> 74004 clangCALL
> open(0x7fffbf00,0x120004,0x2e)
> 74004 clangNAMI "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu"
> 74004 clangRET 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@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
>
>
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
