From nobody Sat Jan 1 02:20:46 2022 X-Original-To: freebsd-current@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 C84451912147 for ; Sat, 1 Jan 2022 02:20:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4JQm2b4MB1z3l0f for ; Sat, 1 Jan 2022 02:20:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641003648; bh=3gJLoHOaq1QLszzhsNChJnyeTatTAmgZH4bHDiJ7UE8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cqQVPzK0/A8JsymyYIQqSB33WwjoYk2dsmXZmkLk3IIQpY15tPmldeJecjCDEmulltJn9MDThpg+ClAx+yjYzoAZduVUWI04NAnTcGnLt9MjjqXkdefKVdMPeIiTgeV9uCa6JJsKR3CzbThk8mizhdSG+ndNm0P7dELaRnbN05uYNnswoggO/1R972wIiC79+w/c0suP4KVSdpvMyQnv978AAPw7VylAJlwr6JcUfUwi9rNfWetFq4WbOWOdXHVJ0LmFlrQ9xmzFtxT4IM1RxbfoaYe+X8naAuOE47oI+z7wAdCIHBlh/N1YmqPnSi0kEhgaNrliE7ZZN659TGvLSw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641003648; bh=IkArqnpoXNLAhxdvzpSTKkrQs6Dfqtd2e4USFkva9xX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jknPxs8C0XSQmTodE8ci4SkAhLn6oYKhlu6BV/mzayBSfUHvzlGOk/RhnOzwaVizJybl7o5RdRCNgo7+jMXmwNBPNpJIRd9lVoqX73P+FczURD/4ACOIH7khfiEjtH6S8eKUuV3Zs9uj3JiBOUUFA6gJNgbb0RD81jiunG6OTHzpJL53oAn5fAHlreWArfAhzIqXe7s0iL0tUm3whEulbXIIJ9cH94a3fS7CY7JIgIX0q6Ywr4CehOuHtp20B9gCpuSSff01I3e1J7zPBc2EXED+W/MbHh2QTAn8nOsJbNrihs0VZUW0bb4juJFKB4w584SKlxgJrxQ0He5dUiGNOw== X-YMail-OSG: TMiE1wgVM1mQfJaya6ynu43km5xP2Kjm.iBXF3zSdkbF9UlsQBihI2twO6oditg T_Z7BBDHJkHja9XB3nxlLgHLj422vlhto.OdW_FjJUtirl4E.7j0yAWQ1DtC1f9i2VEx_5CjYwfD AwPXD6v7lBCySpITuaOnpPS69oVUc3d.FvaBq8mV1IKCBv4va5jGN07a1LdYjdtXZ8MILkQS8KcO ZYvsSPwYrl5pVv3huz887n5uMTraIMefXeu7QU6hzdLnHJJlfzfc7fawIP2p4S.TCgncm5zXA8oi gChtm59Ms_LoJBsgoKxCJ6jyF0DbyZDbG8q_I75H_q6nEQe04w76qpa_2Cwo5FtHLLnfCpLRX8j8 aiayoTAhr1SSH8Nl.FSnBhJk_PMMhfEAnRKsv.VBZy15pDBvCw3CvQhGXmHgZQgLJb0RXfsMPNIe UFXk4icsBLFppNF4wkYnGH.8e1aL0UYPSVBRKaKU15D38gE24ibffFXDtem89Ez_C8kVszDhPP.P DrrOyJiAFoA1sOUzH9NDRKjRE3XX0Q7tZm0TkZEFO5h.t72qG3yW5KP5PIgn2T.Vb8D3BCE0WY9q utvMWMM9TMI6umTVBRfGHq9ikqXbGrOxcpZi_GOR7NMA87yk0_bOKA05hBaad8q_PHlVYWR9JOej CMBnPQ0xgvmjQEatQ0o4K6GaZCL5U.cCf3x8bFMufP_3CXPnXeuZXToGbHSe_Vl4c7FDkyJAIUo9 P4Y5nXsJWXa1j9X6gI8BtlYGAMAJ7BPV99Stf66TmxbMHabqX2EAW5SHvDHvUg.BI1t96r_Url.v _0wiTAJlyuK0mCFZLeLQlYg3QvwYE9IrKtcf_52_3x_p.Cf16RuuwPBkfAItxiXyNipL2GhVJG6p 5wIyRcIGiDslh839BaCKKCu2UAqyrqYce9R6mGKk9zaWG9g3dHPN0quD7Ldv3I.Lz79M49p6ELD7 gnk_2mXlBdBoHapX8vsaJ7f8EgXN4Dpc0mnMXcrj_XPzEWqrGH6BpwwtNDJGNB3NfebUF4_wV2F. ntUEVnD7TvZNCudTT9ba0v7WrXy6sP2BdK845l29_Fu3X6hutee_xShi5zLIJ.2qoq8ioJmfYmGP 7lYowS6YVZ5IytpDVtCXEx0Ac3oCYo1EtzEPsZbmASh8WpJ0z7Pj_hVlFqSm9CR5Mhtb7KOYKLMC McF89vX1HJ.v2uqWy8DhMrjspAgR5tMIIml_npu9otlvv5ZeZkF.XaVAZk.sK3WGFFOWtXg6h8yR hP0jF8dn1bXRGJZOCHMgN2KWydg..IkrpAPAiykwsGlHRVFpxhOE9l5xua19DOJ7eb5TBO3edxNC DIWknlcqk5nkVnLm8SiR6FF.lexyMhuEjsfybjN_rWl2BDYXXcIu7X.PUwwV7oIfc1fYOSYGMr5S 6lVifojPaT2wYeQdg1jVj4BkLqEtAdFKMgoufOSRd3_PW8th2OGNH_36Tr23ecQbokelT1a24LkO YZdCZ947C6cjqT.ResllXo3PxtnTvRYVtiBmXy_0wN74Ryv2AcKZwkoU3SqPZwRSWdvQduhcCtiu i0Lh6m3yb3plQKWzmzcMYCEEhsXG_qLUZIKFEcedAaZmXZipMq7kIOBjRcNchkDY5nxKwWkrz7LJ z95sZiQZR84TrlYW6m6cNsb.Dqacu.fU.DEHazcLqSpF3pdVFOHRFzI9hsLDrNPkeSZznNw5SmPt O3oDXWNSzm8s_DWgot3sdxeRWjBl9YQHEE56tdsE9wt0s6KTJ6544MTT02treou9kXqFrx08gsUS qCYVCiUkEmZpJcLxHrzfAdojvkbsSy2CFpZFuYc3P28j2VDfKe4uGnRtSHwWF09ccNL3H9Y7r84b ZtT2bS3JcvIdJ5GsMWV0z6RbpTxvre.L_M5BAMh7fqkeA5XaFZPb8_ldaxDAkbtoFbLX3DNrKOX7 NMWszRHVpAfYsoGzKo_LjkxcPw7cj5uKhQgeMIN5yGMcDelOjGk5ap8okRUKJxwgBlm1uR9SgbLn Is_g8sHQY0tEKJ1zumQop5JlnpsHej0VGEoTJfRptfS449BvBl6mBm7yWANIpvPYDqtDPxt6ZFnL YceQrvee_lX.ZN2CKWzj7afRDBvQYiqKQ8Fyy1vpvXSYpO.Iq2qCsnpGcIJPve4dM0tJ5uRDvsnw ux_ckQwGjRiNS_f389zZUZctxlLiuxn0Ph0xO89wWVN42RLrum1uPODKsyhHDtMn9D9R3c.F4aXK SONAUW7P8maRu8ntKl3W2rPb9SqclYpZ4knxmG3dpTS1wVsHhgoJe6CzfbYeQmUHmFENRAXg76nn 7IKSp8zzzlnl.br.VyxiRZoye X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Jan 2022 02:20:48 +0000 Received: by kubenode550.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 584fa674c5cff9479f7b1cba09b86d09; Sat, 01 Jan 2022 02:20:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] In-Reply-To: <595C5A0E-B024-46EE-883E-2FCA6ADFE171@yahoo.com> Date: Fri, 31 Dec 2021 18:20:46 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4FEBC148-25FA-4BDB-BFD3-FDBE8D093B9C@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> <82BE340A-321C-43F3-AD7B-2E8466ADA17F@yahoo.com> <595C5A0E-B024-46EE-883E-2FCA6ADFE171@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQm2b4MB1z3l0f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cqQVPzK0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-31, at 18:18, Mark Millard wrote: > On 2021-Dec-31, at 17:46, Mark Millard wrote: >=20 >> On 2021-Dec-31, at 15:04, John Baldwin wrote: >>=20 >>> On 12/31/21 2:59 PM, Mark Millard wrote: >>>> On 2021-Dec-31, at 14:28, Mark Millard wrote: >>>>> On 2021-Dec-30, at 14:04, John Baldwin wrote: >>>>>=20 >>>>>> On 12/30/21 1:09 PM, Mark Millard wrote: >>>>>>> On 2021-Dec-30, at 13:05, Mark Millard = wrote: >>>>>>>> This asks a question in a different direction that my prior >>>>>>>> reports about my builds vs. Cy's reported build. >>>>>>>>=20 >>>>>>>> Background: >>>>>>>>=20 >>>>>>>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>>>>>> and: >>>>>>>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>>>>>>=20 >>>>>>>> Why did libc++.so.1 not get a: >>>>>>>>=20 >>>>>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >>>>>>> I forgot to remove the .1 on the left hand side: >>>>>>> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >>>>>>=20 >>>>>> Because for libc++.so we don't just symlink to the current = version of the library >>>>>> (as we do for most other shared libraries) to tell the compiler = what to link against >>>>>> for -lc++, instead we use a linker script that tells the compiler = to link against >>>>>> both of those libraries when -lc++ is encountered. >>>>>=20 >>>>> A better identification of what looks odd to me is the >>>>> path variations in: >>>>>=20 >>>>> # more /usr/lib/libc++.so >>>> Another not great day on my part: That path alone makes >>>> the mix of /lib/ and /usr/lib/ use involved, given the >>>> reference to /lib/libc++.so.1 . That would still be true >>>> if the other path had been /lib/libcxxrt.so . >>>=20 >>> /usr/lib/libc++.so is only used by the compiler/linker when linking = a binary. >>> The resulting binary has the associated paths (/lib/libc++.so.1 and >>> /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so = to be >>> in /usr/lib. This is the same with /usr/lib/libc.so vs = /lib/libc.so.7. >>>=20 >>> However, your point about libcxxrt.so.1 is valid. It needs to also = be moved >>> to /lib if libc++.so.1 is moved to /lib. Doing so will also require = yet another >>> depend-clean.sh fixup (well, probably just adjusting the one I added = to >>> check the libcxxrt path instead of libc++ path). >>=20 >> Hmm. Looking (now after having updated so /lib/libc++.so.1 >> is in use, not that this is any different here): >>=20 >> # ls -Tld /lib/libcxx* /usr/lib/libcxx* >> -r--r--r-- 1 root wheel 131656 Dec 31 14:19:49 2021 = /lib/libcxxrt.so.1 >> -r--r--r-- 1 root wheel 355764 Dec 24 15:19:42 2021 = /usr/lib/libcxxrt.a >> lrwxr-xr-x 1 root wheel 23 Dec 31 14:19:49 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>=20 >> # more /usr/lib/libc++.so=20 >> /* $FreeBSD$ */ >> GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>=20 >> So: no actual reference to /usr/lib/libcxxrt.so.1 but >> a reference in the DT_NEEDED to /usr/lib/libcxxrt.so ? >>=20 >> May be just /usr/lib/libc++.so needs different text in order >> for DT_NEEDED to have different text related to libcxxrt in >> future build activities, avoiding /usr/lib/ ? >>=20 >>=20 >> For reference: >>=20 >> # uname -apKU >> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #27 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:00:41 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400046 1400046 >>=20 >=20 > In a aarch64 context I looked at an old executable via ldd -a : >=20 > # ldd -a bt > /usr/home/root/c_tests/bt: > libexecinfo.so.1 =3D> /usr/lib/libexecinfo.so.1 (0x41c19000) > libc++.so.1 =3D> /lib/libc++.so.1 (0x42484000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x43038000) > libm.so.5 =3D> /lib/libm.so.5 (0x44a4c000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /usr/lib/libexecinfo.so.1: > libelf.so.2 =3D> /lib/libelf.so.2 (0x4581e000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libc++.so.1: > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x43038000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libcxxrt.so.1: > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libm.so.5: > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libelf.so.2: > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libgcc_s.so.1: > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) >=20 > Looks like something already deals with finding > /lib/libcxxrt.so.1 . But it is not obvious what > path it started with and how much processing was > done (or when) to end up with /lib/libc++.so.1 > showing. >=20 > But there is still a /usr/lib/ reference overall: >=20 > /usr/lib/libexecinfo.so.1 >=20 > But this is because the old program turned out to > be an old experiment: >=20 > # more bt.c=20 > // bt.c > // from releng/12 (12.2?) context (pre-llvm12), but not releng/13 : > // # cc -o bt bt.c -lexecinfo > // # ./bt > // Rerun in llvm12 context, such as main after the switch: crash. >=20 > #include > int main() { > void *addrlist[100]; > backtrace(addrlist, 100); > } >=20 > Although, for some reason, the executable was dated > 2021-Jul-15, not that I remember why I'd rebuilt it > then. >=20 > # file bt > bt: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 = (1400025), FreeBSD-style, with debug_info, not stripped >=20 > nm -a bt shows: That should have referenced: elfdump -a bt | more > entry: 0 > d_tag: DT_NEEDED > d_val: libexecinfo.so.1 >=20 > None of the DT_NEEDED entries had paths shown. >=20 > The only /usr/lib/ reference was: >=20 > entry: 65 > st_name: /usr/lib/crti.o > st_value: 0 > st_size: 0 > st_info: STT_FILE STB_LOCAL > st_shndx: 65521 >=20 > Overall: backtrace requires /usr/lib/ accessibility > for main-n252090-5650d340ad66 in order to access > /usr/lib/libexecinfo.so.1 . >=20 > For reference: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #34 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:30:22 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400046 1400046 =3D=3D=3D Mark Millard marklmi at yahoo.com