Date: Mon, 19 Jul 2021 10:57:11 +0100 From: David Chisnall <theraven@FreeBSD.org> To: toolchain@freebsd.org Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) Message-ID: <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> In-Reply-To: <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0563fd33-75bd-ff16-2d37-ce62f15fa4a9>