From nobody Mon Jul 19 09:57:11 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AF1412A664C for ; Mon, 19 Jul 2021 09:57:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GSy1l0JLSz3pn4 for ; Mon, 19 Jul 2021 09:57:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id E0C3A2E2D0 for ; Mon, 19 Jul 2021 09:57:14 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-191-32-244.range86-191.btcentralplus.com [86.191.32.244]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7A19D2AE1F for ; Mon, 19 Jul 2021 10:57:13 +0100 (BST) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) To: toolchain@freebsd.org References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> From: David Chisnall Message-ID: <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> Date: Mon, 19 Jul 2021 10:57:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 In-Reply-To: <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 16/07/2021 12:15, Mark Millard via freebsd-toolchain wrote: > As far as I know the /usr/bin/clang++ related FreeBSD > toolchain never has a file aarch64-unknown-freebsd14.0-ld > in FreeBSD. (And similarly fr other suffices than ld.) There is nothing FreeBSD-specific in this behaviour in clang. If someone wanted to provide a different search behaviour for the clang in the base system then that would be possible, but in general I am strongly opposed to any special casing of behaviour in the system compiler. It's already incredibly annoying that the system compiler doesn't search /usr/local/include and /usr/local/lib so everything I build on FreeBSD needs to be explicitly told 'yes please do actually search the place where the system installed libraries, thanks'. > In other words, why is aarch64-unknown-freebsd14.0-ld > even listed in TargetSpecificExecutables for the system > toolchain's clang++ ? It isn't. It is part of the generic search logic. The search logic says, when compiling for {target triple}, prefer {target triple}-{tool name} over {tool name}. When the clang driver looks for ld, it looks for > I would argue that the default FreeBSD system toolchain > configuration/operation should be adjusted/patched to not > have automatic defaults that cause parts of that toolchain > to not be used even though they are present, just because > some unrelated/independent port(s) have been installed that > are a different toolchain. (Explicitly enabling/allowing > alternate matches may well be reasonable.) The only way of doing this would be to completely remove all search logic and hard-code the paths. > > As far as I know, there is no guarantee of compatibility > with the gcc/g++/gnu related toolchain, with the error > message that I reported being an example for attempted > -flto use. -flto requires LLD. You can force that with -fuse-ld=lld. Clang then will only find things called [{target triple}-]ld.lld >> See the Driver::GetProgramPath() function: >> https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Driver.cpp#L4981 > It looks like if there was an implcit/automatic -B /usr/bin > when /usr/bin/clang++ is the native FreeBSD toolchain one, > that the problem would be avoided. > > But, as, stands, that has to be done explicitly on the > command lines in order to tell clang++ to use its own > related FreeBSD toolchain instead of using one from > ports. But then we'd have a divergence between the system compiler and clang installed any other way. It is expected behaviour that if I install a tool prefixed by the target triple then it will be used in preference to the system one. >> Note that the native binutils package does not cause these problems, >> since it prefixes its tools with $arch-portbld-freebsd14.0. E.g., the >> 'vendor' field of the triple is set to "portbld", not "unknown". >> >> I guess the flavored binutils packages do use the "unknown" vendor field >> to avoid installation conflicts. But at some point this should be >> resolved: either all binutils ports should use the "portbld" vendor, or >> all of them should use "unknown", but this mixing is causing trouble, in >> my opinion. > It has been all portbld at times in the past. That mix is also a > problem. 3 distinct naming structures are needed, not just 2, in > order to prevent mixing from occurring without some form of > explicit request for a mix. Setting the default target triple in the base system compiler to use freebsd as the vendor would avoid this problem: Unless you explicitly install something as {arch}-freebsd-freebsd[version]-{tool} then the base system clang won't use it. David