From nobody Fri Jul 16 11:15:21 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 EA79D8D5E7A for ; Fri, 16 Jul 2021 11:15:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GR7vP4PGLz4kfk for ; Fri, 16 Jul 2021 11:15:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626434127; bh=l0zinONBxU+BgzSrIhPsxQBn4fQGT1XtmHlY//qwng4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WZOVgiBpMd9G7jWYxL5DClWzNPTRqj25/3jFAYtdpU95gqjeS46JXPoADrrmaeIr2896VX+i0zO+3kzR8Sp/RYGJ8TT/Gk58jk26FummtMm/uFpiML04guLZknudo58LCEAPbhmemQAJTTOR5o2QV80cqnRu01wbWsFJBHPd9pbHRmpu4AkGJNQCzq4h10sDAI1LSAVtB/eE3PWIZkeZBrNqJkIPEDJW2f6zfks807Z7fKz43537PfvFYTL6CHu0WgzDd+8WrBEbhx2eUY8A2R5NNNf75LIbk4WvbpeW4t9lwQcnZX/n6CFFyhGEhW7wUBC0zsZwmZMs+mRvsXMsWg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626434127; bh=6jFte05mqBWQTgAVdEX0HFjRy8EcYY04J23UTqsb6fc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hp3EsZXqr3rVDdK1cXUHubgUlpdwnzwr0RGM0TQdQ7m41QycQmf8bwkQNqnYcKQRUBg2cbTjvoUyKdUCjBfz4brMTKKekHIB9CP7SPquFZmKX9+plefRlwVbr3yMWjcp505+Movs+Xshgk4gVk34qIUIgRx0+mORg/2HZ/6C4zh0y1JK+ARPZEM6QKXulo6k2tch4brdbb0QS+bvig6dG59ITUIzn2ILspIAjQsw5z9o1VtPl3G40X5J1QTC0CnZ4PZzdqay/1I8860v0u2uE8ZGnO5H+4QAexDOjN/XYQ3bQGZF+Z9ANt82k8AbXWjzIbxqz9U6MW0PNCcxFwnaLQ== X-YMail-OSG: GHenS8cVM1lNDEp3aI12EynqGC48g2l0xSjl1BREzXRkFTQHhFNLdf2s25x.uKn rWtlQw509jK8GNhC4iZGjw92O5Df0pBQSIi_S7ab4onhtH.7VWOTy.bi4VWrLPS6N5dt.cVunGVR JZCFsoFmnsUTffvCawwgY_PVkOTw.zz.KOeGJy7nHVg33V1m2IggmBdKvNEKpGPbNDDW17yYNzPW j5PILg99Cdct6T4WXdrYBKp5_4f4SOOfxI6rpIegvVE.TrcpjfTUgK3L_7Iwrp9sB8sh0GvWyUhy ECWzOviWWhCAl7y5Wib991mgoZh0BGAUP7L63Vof1r2FerV_u1OtpYZoDxUINp90tspqxXlyBgwv kVKebQ3Q1.TLGECon_OZeO.kxiV0GxDAG3s59RIGDs9jiFSX9arIrhlea3Xg3dSMW.kG6EzgkHMT I3p.P97QzeMfTfDcWEcEgoaUxWzSEuPeSFnYprnDcEXiUn6lhL5dDO9uzJ0nj6LTNkLwL2PWCO.c F0QDDrQMQZdbaf4a7GN6od6OuGAIQjdZuNyI8EaS3ue4SDUjBuDdKo9jsGYFqcxG7RinG1oRFI39 ObOtFqgJt1IIkXnlRgwMAOFV5UJS2MKcbk.HgC8DOT_tC_C2igvOPfWDl4kEJeekZIA9avFIrf07 FihPqf1nZ2NPt58G_A_SwPP7wB020Yd4KtTN0KFa3I5HzjuPzcsL4xntl0wCZFIx2Gp5lmAoMnWM ZgS8vG1V0LJke8EOLF7pnGEWeOAMXVlOJuXWQNQ73_B5Dpdc65LPOZVV37Uwm5X0piqPqtGthhVk IljhFjuPHy7u3Xq6LTfSytCmR2P.g6Lwjebx6FBjCKLFiiaG1diU0MhVtGJjC18BJ7aZszNWQEEP 2lfWC9OEESWaeX.2uVFl.wkKLfnwFSO4Zg.AiTtivHplKj2tkjhHOdhVYucQdbbbzAgJOFR0LQkQ pKnQJFnZ_vkgE1t5oY06WX3wA.gf2X_YBclUwFHwkH1yoCqsMWNSzVUVDGuU8FCjTNx9EoDP_n46 9jK95IFB6zEp3Rr0873nZpE5z5oJtnHxdZ7m3aE8.cO4zvn7ij5zu2Ua.qylaOKD._ZWbcsSAbLz im7fhGkROhry9AHF00vo1HgQpYl0Z.j12Dzc6y9DsMC96RFgo2Wiury.TNb3b4bmi6zwPRBwdoa8 eS57v4FCvjEHsL6dyGbNOqYcMf04Fhd2jpA17KP7u0iSewSOcTrytCDf5kQ6Tl6Y2PK0iBupA8a7 H4oKNvG7YzJREHl6YoAtwj9HmpYFFAPM9a47YIV2FVMZPpRnA4nPhIWiixxlSNozeA99kF9k6xI8 htOCjrPxZSuFja0AkAou24766FYZkfUntp2_ARw57qVEzC4opgqRWi2buif.dnrvjU7tOQRImJkC Fp_8HhvHtYOhglLyc_8uKo_aNV_YNyl5OMgfhE1ktth5hdZqMmb8Of.MW.iAs2f1iRqEAtECXq.x TvMmVx0fRIYMPXZDtqHy0apV7hFdCR2HLNoFiSTMV_AI_g0hX6SXG7uOXCncCLRz_BsqDffl_zJk ggn0agGbZmP1vr5WPcC9fvg57vA2cE4NVXdFr_JxVOjBilHInLzt1ogj5UfNGlWABkvTC46AvQy1 zh1MrNcBR1wTVkxzBnkv4EWweDQAgLpfwF8kpXfbOI20Cre3uwfvnhtb5SONbi1Rh5uKdO.9zZTI 3DLjlO6_vKK7Cs45xuYRSaMdN5ogai3_9zrCvAyqpPzkH.jYMxDFdb74HxrOPtX9tjcnmUFr5JAO yfTkeHlFJHGpeMG2oRnq5MM3PZwnV0nPTrBDAri.R1toQ.LaaKi.f0lNaCfem0ci9Nr91hVcw.2w vqhfQhZu3FBu.RZaNdX28THJ3gGTIuNqwpn9T1galRr_80dQh6ifmGUpQEqcp4PHE1BVEoq2tDS3 J4qM5wdeHWZqpl2uzdorG1FNMaAS1JBR4JXxJiYi3MywYee0Qi.wQI5AeTnqOde0_u6Ht8YzUMBY fvMGGnzEPpZa3I7UTwrBX3_cF1FbRnsysn6CdBXSEgzqLSJLd4cPBzxFniOOZIhOrM3sY6tq72Y_ cez59V_MxWJux.AGwWNNFRDenXJAB00dRXixcvTpMSap6QkPl0yTotQqlzzpNgA8nStZhTTeYzaM 6aKA.2HrhsswgGdidfyhAamGJyqiOlQpz05OPEEc1HeTIs74HyhptTkLTv5EYxEMZMfqOiSc88s1 f5uV1dKI8CS1alAJmc1UsvE48OCrzKj9RSP_lTp37BYc0Rf1_tLZhUMn3VTmJZmWjknz5uqfgZLb zW4FXGjVNQvVbhvvu3fdb0pRcXklpmokaRD__fGUskldri7zZCXjw46ikPskEjjcCYXyJHgbCMsp wlwdL5AsDMTQEp2qht7qok4JJGRhXE_eAJFy1fsZUV6Ao6vQKeXuFMzemBCs3ehA561ShySnJw8T vHnzX1_K.fP21YstwBixlPGo1ogp.vbj_RyJfDdnlLxt1ThKgJkI5JJxdfRqxlYlWJucVwcLPr0I U3IBzqekYYX9peqs.dcN33NQUAsf9Fe4Ig8ik044PI8Mc9QEfgfzswwBvrtLthIVVSOeuzEA8GGG oYPldhy.waX_aC2i.TT_I8eOfG5TXYWf8oPF0iN0d1_E_XYc.kkBOEJvLGXtnsEZvMJagrN7UzNf SK1ty X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Jul 2021 11:15:27 +0000 Received: by kubenode531.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 55cda72347ba0231ac87480d824973ee; Fri, 16 Jul 2021 11:15:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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) In-Reply-To: <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> Date: Fri, 16 Jul 2021 04:15:21 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Dimitry Andric X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GR7vP4PGLz4kfk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N 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. 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.) In other words, why is aarch64-unknown-freebsd14.0-ld even listed in TargetSpecificExecutables for the system toolchain's clang++ ? 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.) 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. > See the Driver::GetProgramPath() function: > = https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Dr= iver.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. > In short, if it finds aarch64-unknown-freebsd14.0-$TOOL in your PATH, = it > will prefer that over $TOOL, even if the 'naked' $TOOL would be found = in > an earlier PATH component. >=20 > For programs like ld, as and such, these will be found if you install > the devel/binutils port with an arch-specific FLAVOR. In this case, I > assume this was because you installed a CROSS_TOOLCHAIN package such = as > freebsd9-gcc, or directly installed the aarch64-binutils package? # pkg which /usr/local/bin/aarch64-unknown-freebsd14.0-ld /usr/local/bin/aarch64-unknown-freebsd14.0-ld was installed by package = aarch64-binutils-2.33.1_4,1 # pkg delete aarch64-binutils Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 3 packages (of 0 = packages in the universe): Installed packages to be REMOVED: aarch64-binutils: 2.33.1_4,1 aarch64-gcc6: 6.5.0_3 aarch64-gcc9: 9.3.0_1 Number of packages to be removed: 3 The operation will free 278 MiB. Proceed with deinstalling packages? [y/N]: N So /usr/local/bin/aarch64-unknown-freebsd14.0-ld exists because I built and installed: devel/freebsd-gcc6@aarch64 devel/freebsd-gcc9@aarch64 devel/binutils@aarch64 > 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". >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)