On 7/17/13 5:33 PM, Roman Divacky wrote:
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
Thanks for that patch, but when applied to the 9.2-PRERELEASE
clang tree, a buildworld fails like this:
building static c library
ranlib libc.a
building shared library libc.so.7
/usr/bin/ld: this linker was not configured to use sysroots
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libc.so.7] Error code 1
1 error
*** [lib/libc__L] Error code 2
1 error
*** [libraries] Error code 2
1 error
*** [_libraries] Error code 2
1 error
*** [buildworld] Error code 2
1 error
-Kurt
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 <stdlib.h>
#include <stdio.h>
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 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@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"
