Date: Thu, 18 Jul 2013 08:48:27 -0400 From: Kurt Lidl <lidl@pix.net> To: Roman Divacky <rdivacky@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: clang looking all over for linux libs [9.2 PRERELEASE] Message-ID: <51E7E41B.3030504@pix.net> In-Reply-To: <20130717213347.GA23999@freebsd.org> References: <51E6FAF5.3080802@pix.net> <20130717213347.GA23999@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51E7E41B.3030504>