From nobody Fri Jul 16 18:41:07 2021 X-Original-To: freebsd-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 6472912428CC for ; Fri, 16 Jul 2021 18:41:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4GRKnm24yQz4RfT; Fri, 16 Jul 2021 18:41:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 0472F2FEE4; Fri, 16 Jul 2021 18:41:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2001:470:7a58:0:cc9:cc71:af17:9c18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A39CF265F0; Fri, 16 Jul 2021 20:41:14 +0200 (CEST) From: Dimitry Andric Message-Id: <92C044AF-ED44-4815-B8B5-318DA21F551B@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_245F6241-BA43-4C8D-9AD4-38772374BA31"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Maintenance 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) Date: Fri, 16 Jul 2021 20:41:07 +0200 In-Reply-To: <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> Cc: FreeBSD Toolchain To: marklmi@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> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_245F6241-BA43-4C8D-9AD4-38772374BA31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Jul 2021, at 13:15, Mark Millard via freebsd-toolchain = wrote: >=20 > On 2021-Jul-16, at 03:23, Dimitry Andric wrote: >> On 16 Jul 2021, at 02:21, Mark Millard via freebsd-toolchain = wrote: >>> # c++ -v -o trivial trivial.cpp >>> FreeBSD clang version 12.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-12.0.1-rc2-0-ge7dac564cd0e) >>> Target: aarch64-unknown-freebsd14.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>> "/usr/bin/c++" -cc1 -triple aarch64-unknown-freebsd14.0 -emit-obj = -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier = -discard-value-names -main-file-name trivial.cpp -mrelocation-model = static -mframe-pointer=3Dnon-leaf -fno-rounding-math = -mconstructor-aliases -munwind-tables -target-cpu generic = -target-feature +neon -target-abi aapcs = -fallow-half-arguments-and-returns -fno-split-dwarf-inlining = -debugger-tuning=3Dgdb -v -resource-dir /usr/lib/clang/12.0.1 = -internal-isystem /usr/include/c++/v1 -fdeprecated-macro = -fdebug-compilation-dir /usr/home/root/c_tests -ferror-limit 19 = -fno-signed-char -fgnuc-version=3D4.2.1 -fcxx-exceptions -fexceptions = -faddrsig -o /tmp/trivial-5d90b5.o -x c++ trivial.cpp >>> clang -cc1 version 12.0.1 based upon LLVM 12.0.1 default target = aarch64-unknown-freebsd14.0 >>> #include "..." search starts here: >>> #include <...> search starts here: >>> /usr/include/c++/v1 >>> /usr/lib/clang/12.0.1/include >>> /usr/include >>> End of search list. >>> "/usr/local/bin/aarch64-unknown-freebsd14.0-ld" --eh-frame-hdr = -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o trivial = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/trivial-5d90b5.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed = -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o = /usr/lib/crtn.o >>=20 >> Yes, this is an unfortunate (and sometimes unwanted) side effect of = the >> way the clang driver searches for its linker(s). It prefers "target >> specific executables" (meaning, those beginning with the target = triple) >> above generic executables, when searching for linkers, assemblers and >> other external tools. >=20 > 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.) No, but maybe we should add a symlink? :) (See also the discussion recently about the order of /usr/bin and /usr/local/bin in the PATH. But be sure to have some popcorn ready. :) > In other words, why is aarch64-unknown-freebsd14.0-ld > even listed in TargetSpecificExecutables for the system > toolchain's clang++ ? This is because it is a usual practice on many operating systems, in particular Linux of coourse. Cross tools are almost always installed with triple prefixes. The TargetSpecificExecutables list is filled using this function: void Driver::generatePrefixedToolNames( StringRef Tool, const ToolChain &TC, SmallVectorImpl &Names) const { // FIXME: Needs a better variable than TargetTriple Names.emplace_back((TargetTriple + "-" + Tool).str()); Names.emplace_back(Tool); // Allow the discovery of tools prefixed with LLVM's default target = triple. std::string DefaultTargetTriple =3D = llvm::sys::getDefaultTargetTriple(); if (DefaultTargetTriple !=3D TargetTriple) Names.emplace_back((DefaultTargetTriple + "-" + Tool).str()); } E.g. it puts the 'tripled' version of the tool before the 'naked' tool. > 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.) Well, the question is how you would explicitly enable those alternates; yet another command line option? In any case it would have to go via upstream, as we don't really want more customized hacks in our version of clang. That said, I think I agree that the current behavior is not really what FreeBSD users would expect, and it is not very likely that you would want to actually call the GNU linker in /usr/local/bin/foobar-ld.bfd. So that's going on my list of things-to-implement-and-submit-upstream. -Dimitry --Apple-Mail=_245F6241-BA43-4C8D-9AD4-38772374BA31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYPHSwwAKCRCwXqMKLiCW o90ZAJ0d17HWkb8B48/fA4PysnhBx7CZvACfbBJ39y3ktkssukcYf7r9+2IdNd4= =0WUg -----END PGP SIGNATURE----- --Apple-Mail=_245F6241-BA43-4C8D-9AD4-38772374BA31--