From nobody Mon Jul 19 12:35:21 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 4D216127E0AB for ; Mon, 19 Jul 2021 12:35:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4GT1XH0947z4jtw for ; Mon, 19 Jul 2021 12:35:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626698124; bh=qouXfMz6KYuOXq9DdIBWpynrrAHDz4yWWtKUNjDjLp0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=d87NASU6W4szuKWnqysD2Hvnk2wWou1F5o87PXHtA5lU8QLp55+hHkyFZ3pgGbu5lNAdNJmw+4K2sRyYyVvXycnwJtWVAWZJ48E3Cp/BQxCIee6Hsn9gRfPwdF1HfznUGpnEd9F8VIlYO1Unm1T2QU776WKoGRQ4RKZlmOWefXAn/nHlDsrtY06BGFCJu94CBD3BN4bx2n3ql2yOHfmYd5n1ISv2QKysLBh9saZoQYOtQmNu8692+lkNQCKEbTPQPwop1/FXW5Zd4NCaIbrK2L/nWCiUvZAzvvmR7LSiZJUWNYkDVjQ72GddNjHBLaTic6ovjBBiQPEX4eXzw245WQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626698124; bh=62mhLQheeAHA6Qk0vBdivyT/6bVRg16QVT2loWHX/JF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ddRQDI+tX+yTecc/i/qLFxSWuplNt+uAC5O9i29zK6lHG4MfcZj/EkUfsWT/aDikT84ZFOMB6MkOKzORTgCZZ5DcIYG46PdfMzkuTQcfqOfSrw6su3p6x6DLuuWJzC3WSUcxUmDisKbxhx5BxMiad8P5BNwUyfEyWjGFFnRGjGIHsIyGfSagRVRroVm/hmy4ZbRMQft7S0jdld3MpSq5m39umgj1w83iFEB3cCJO0JvK7a0FwPxOJShCvwRkkfCpf6AV5xH+BwLnGWrvhlpzqlyBhy6UAgtnuAiITMt3GK1oAjuEaC0i9May3AhApROk6APtpy83Z/Zju2MAZ5P2BA== X-YMail-OSG: 54dNl9QVM1mejRL7APMGy4t5Lxxt6qEuS1icCnIU2rroMrASOegXKwBqRdbn71h B_4X0yUL1h5eoZNz5Ydn0mS5hIT74OEcvCaIQmQT0HITiamJChC3x9PYxXX2FxElmaP7i026bGBd D5eA1Bsvahbz_xaCe3LZaUzvkRpr8GeKVJisPfCGGoAaJ1AqJs8nGhO_7U82DSxRpUnO2WJfVtie RFsOY6Db.hTp0d_Wx.D8XzFacvS0_XTXXBoYVw4Wu4rarvEuywaXvd9aL5clRaV2Km9d5vsCbaVL .uvuC8IQZLlaHQoY3HeJv4OpkYrAvzs6diyVy9E2m22Wfn89tfvuhDKb14FcA3.HG2vc5L.eeHl7 UCkKUGPBE.pJwFIKDS7i38houFW6bYVPc3iclxjTJ8AbP4qoVBKVQFcWkGdFoAgRFpZYv.daGdIY AhgX_P.xjvwQcErfeRggIVkfHFr2cdned1Q4jitr9gBKjp0BgDb0ZduEE9alEy5C3Gttur1kIM5K 52_lF_0.C8YCichC1oamiVzijMzgr90ZSaWBI8eiq8bR0e8s3bpuuFY06asEsimOgRgEemczl.3r VneJXZ8Nk_b9smkNeLoL3hiprSOxiXFjCgFfZYNqd_7mGY9yovgJZWU9tkIvuv27Ki7yThXYjJ1R cZ9yBdtM9rZYvHft.Canbn2ftPVoH_6N2v2u2.0Jlfj.KabvQL6coZr.3faEj6QWNtaemvD6Yqcw YQPZ0BcQN.QmcKh5bxfDx_gAsrcjO2cfKULU4vRyTSSF3cek4lviBkopBpQPnn8Aq_eLzKXidDse SS8yPONEcVNzLSMNQXENGHmy6u2SgkbWZoA9BhzjRYVYYxjECLj1MsgAyAVR.PnZEkTAhJsV8iMl 0ZkTHfIVToDcELl1vovtOmDxQdMD2NAiBE.YzA8WSOvSSUVDz9KdUWuoF0ShX5GD8yqP7V8NtFCd Etb4QkBMyf6t527.E6OgldMhza2g6VVCcRYoL45uWD0Zu4koN.m70b8F4hJsD1C9W7TYIalVAmy1 CQNiDycAY6HsrSioCliJvwjSaQ_HDVWNGYRb0xsUbVHypoHjFZzk8cWOtXUfOXwuzggIby35.7OK 2iCLczRPLmItAI.FhuRI9tZyZijtua65Xdq5oWkECp8t80XR7rmke_VUerfxKkTzDSfN4UYh86ei YeeFZRlmPjW77NgQzqODB4OlMbvTz2VUf6zAVn_XWGJajaPeXJjIDsPZoILVpvNuzZy9a0K5CC0K NwmEzN9j43UpeiJveuMP9iUUTuG.T.588ONl6wB1FKPZ.QpSqJpyIVyPXnFOKkEm3Q0j4_rXHQ9t aXrBlWRfvYISWJoWBBcHqGMn_URjVCZkg77Z0E.OPKCPQTn_BQZnMLmyeGmpByX.7OCgriPCJlFN 16HqrkBXGLamoPH7MSTok8p2MKtsxzykJ7iWPUXkmtLUuuwXC4SHCcvvIQpStjkJx_s_luyB9bb. LYp4iWCB_1ZqgA5EdwsG6BCkKdrLxLzPuPSs204G1bc_sDf301X3Gz02pkXI_272ChbQwtYOJ9Wc kb2vU_P102cnc905Gyh8cJ8Xuq.OXBThrmiicwiAkHldMbt2ZUcHKC_YPuv1RWfxbUzOkifsEcHh .sgJo.uFGuRstCb8i14I3QU627O.rW2mw8TjFROucgGnMOeF2k9TuHSqnGR14mFOeCi_m_Q7D8pp .Kk7e54rhhdl2pYMWERtnuZvR6JFB_GUwJNtScJkkCBYqIs2KJ873iJfIPF6lvXACSA51p6CDJ8f 4I1VG9a97yf4bwjfwnpfgl.mTv61lt4UrnX4KCEBIyzuyJ6Cc.5JMfkLMgAQlztE2bFuk_bxSYMt YLtltL0VAdEcXPOaJOAdSbWvkKeoLeoEvRBKp94NdsFOfvnBzK7S4Dyix1B9_7JO6fxFxPTVEPl2 q_Qjfd6_LLzZ9lDvhvTM97RcRE2LziOy.dLHuaByRkzvkuv0ogHveKzDIJLnGiq29ZZngq13DTM_ WYxGOjb3OEWxZVvVbkpHse.T_FrB9_7SOGz9IuuN5cesKIBiL0ME74bEY9uRogcS1ldWhNCosZ0T fJEnBpoGCb8ZrfJ13JvV4.a9FTPcJlPwPQAR2d7kwOEP4q.Lobj_gSVIt.UYDeECjdbK_wNQW1ZR VlWZowtWdwC7plUuPBgpMDjvDD2BORRvoK59GRdR_iCU0m2_hAX.MN2CMyIKSU973KSnQVvD.7pI QjdyWhZ.hdkLnwi0sCmkJXLxP3WcZx7hB8IRk5g7RH2nk3Cc7aFuR17gSZ3EYG970IfNgzt.B1Xl aCLEreiilZ3hWWohZ9XfZ8L7gesGBbt3brpY_iJT0dJRfKgOPd.fM2cg4clJIEsZONlqThPNuS0o zULC6yJlilNv4JmNwx3YWybX4fsHF_p2IZPxEYZgnluM8o2KbZXOdNuKUtBCPGkKDEEhPevnMgbo geu_43TrJhg_fuUdWspQ_sxYsn7385Lf3XKoha1em8j5flLb3KKtYlqXO0ORPNxQC5HkRMzsQi_W dwET4Fr6gCcJGgAgu7TgyhBb7GO7mSpc1szFI2pfW91h_UbJtV1ZZArto8H1u7r8c X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Jul 2021 12:35:24 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9c839c813e69c08c885ec105ab4989c2; Mon, 19 Jul 2021 12:35:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (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: <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> Date: Mon, 19 Jul 2021 05:35:21 -0700 Cc: toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GT1XH0947z4jtw 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 toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-19, at 02:57, David Chisnall = wrote: > 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.) >=20 > 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'. = https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Option= s reports that gcc does not look in those places with file name prefixes for cpp, cc1, or ld. It makes no mention of looking based on a prefix ending in text analogous to: aarch64-unknown-freebsd14.0- So there are no words about such names having priority either. And gcc uses /usr/lib/gcc/ and /usr/local/lib/gcc/ in preference to using PATH entries as prefixes, stopping on the first match found. (This and other wording support later comments about a fairly common industry practice.) >> In other words, why is aarch64-unknown-freebsd14.0-ld >> even listed in TargetSpecificExecutables for the system >> toolchain's clang++ ? >=20 > 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 gcc is not documented to do automatically do such that I've found. >> 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.) >=20 > The only way of doing this would be to completely remove all search = logic and hard-code the paths. See the likes of what gcc is documented to do for an example from the industry that need not match files from other tool chains because the search starts with special places for the specific toolchain and accepts matches found in those places in preference to other places. >> 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. >=20 > -flto requires LLD. You can force that with -fuse-ld=3Dlld. Clang = then will only find things called [{target triple}-]ld.lld If I specify -flto (which I did), why is the command invalid by definition (produces an error message) and so require more command line options to correct the behavior to not get an error? Why should the installation or removal of a incompatible tool chain change the status of the system's clang++ command line? (The message is far from an obvious one as well, complaining about a missing file path.) There is another message from me where I note that I'd figured out the -fuse-ld=3Dlld hack, although I omitted "ld." in the example: should have been aarch64-unknown-freebsd14.0-ld.lld . I'm actively using this technique because it seems to have the minimal other potential consequences. >>> 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. >=20 > 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. In the industry, it is fairly normal for a tool chain to have a place unique to it that wins unless something special is specified. (And that is after lots of variations have been tried over the decades.) I've tried to illustrate that with gcc but it is just one point and I do not claim there is universal following of such. >>> 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. >=20 > 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. Yep, relative to this matching of files issue anyway. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)