Skip site navigation (1)Skip section navigation (2)
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>