From owner-freebsd-toolchain@FreeBSD.ORG Wed Jul 17 20:13:42 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9AF040A for ; Wed, 17 Jul 2013 20:13:42 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC8B8E3 for ; Wed, 17 Jul 2013 20:13:42 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r6HKDfx8075871 for ; Wed, 17 Jul 2013 16:13:41 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51E6FAF5.3080802@pix.net> Date: Wed, 17 Jul 2013 16:13:41 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org Subject: clang looking all over for linux libs [9.2 PRERELEASE] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:13:42 -0000 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 clang CALL open(0x7fffffffbf00,0x120004,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,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