From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 6 18:47:31 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92B8FD24 for ; Fri, 6 Dec 2013 18:47:31 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [95.129.96.251]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEC11660 for ; Fri, 6 Dec 2013 18:47:30 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 5CE8C1CC5592; Fri, 6 Dec 2013 19:40:21 +0100 (CET) Date: Fri, 6 Dec 2013 19:40:21 +0100 From: Roman Divacky To: Kurt Lidl Subject: Re: clang looking all over for linux libs [9.2 PRERELEASE] Message-ID: <20131206184021.GA66137@freebsd.org> References: <51E6FAF5.3080802@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E6FAF5.3080802@pix.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:47:31 -0000 Fwiw, I fixed this upstream. The version 3.5 will hae this. Thanks again for the report! 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 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 > > > > _______________________________________________ > 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"