Date: Thu, 30 Dec 2021 19:15:51 -0800 From: Mark Millard via freebsd-current <freebsd-current@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Dimitry Andric <dim@FreeBSD.org>, Ed Maste <emaste@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib Message-ID: <8F2CC835-812C-40F9-9097-B28AD8405737@yahoo.com> In-Reply-To: <202112302314.1BUNEPt5016004@slippy.cwsent.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <202112302314.1BUNEPt5016004@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 2021-Dec-30, at 15:14, Cy Schubert <Cy.Schubert@cschubert.com> = wrote: >=20 > In message <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com>, Mark = Millard=20 > write > s: >> On 2021-Dec-30, at 11:52, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>>> This commit results in a different error. >>>>=20 >>>> ld: error: = /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2 >> :=20 >>>> cannot find /usr/lib/libc++.so.1 inside = /export/obj/opt/src/git-src/amd64. >> am >>>> d64/tmp >>>>>>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>>>>>> ^ >>>> c++: error: linker command failed with exit code 1 (use -v to see=20= >>>> invocation) >>>> *** [libclang_rt.asan-x86_64.so.full] Error code 1 >>>>=20 >>>> make[6]: stopped in /opt/src/git-src/lib/libclang_rt/asan_dynamic >>>=20 >>> Working in a system that had the file removed and then >>> manually put back after the upgrade, what I see after this >>> new rebuild (not installed) is: >>>=20 >>> # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-nodbg-clang/ >> usr/main-src/amd64.amd64/ >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= / >> libc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= t >> mp/usr/lib32/libc++.so:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so=20 >> ) >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= l >> ib/libc++/libc++.ld:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so ) >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G >> ENERIC-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such = file or=20 >> directory >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/u >> sr/include/dev/ic/esp.h: No such file or directory >>> = /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 >>>=20 >>> That has /lib/libc++.so.1 (outside lib32 materials). >>>=20 >>> But it also has: /tmp/usr/lib/libc++.so and is that a problem? >>>=20 >>> And, checking on when the files were modified: >>>=20 >>> # ls -Tld `grep -rl 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-no >> dbg-clang/usr/main-src/amd64.amd64/` >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G >> ENERIC-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such = file or=20 >> directory >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/u >> sr/include/dev/ic/esp.h: No such file or directory >>> -rw-r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd >> 64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++/libc++.ld >>> -rw-r--r-- 1 root wheel 72 Dec 30 08:22:11 2021 = /usr/obj/BUILDs/main-amd >> = 64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/lib/libc++/libc++.ld >>> -r--r--r-- 1 root wheel 72 Aug 19 03:09:03 2021 = /usr/obj/BUILDs/main-amd >> = 64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/tmp/usr/lib32/libc++.so >>> -r--r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd >> 64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so >>>=20 >>> So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been >>> updated. >>>=20 >>> I used META_MODE. >>>=20 >>> So I do not get a full match to what is reported but the use of >>> the tmp/usr/lib/libc++.so path does seem odd. >>>=20 >>> I've not looked at what a system from before the first move of >>> libc++.so.1 does. I may be able to check that in a while. >>=20 >> So I've now looked at a build (not installed) that was done on: >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 = main-n252010-254e >> 4e5b77d7-dirty: Tue Dec 28 16:04:12 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/ >> = BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-= CA7 >> 2 arm64 aarch64 1400045 1400045 >>=20 >> which is before the original attempt to move libc++.so.1 . It shows: >>=20 >> # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr >> /main-src/arm64.aarch64/ | more >> grep: = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/us >> r/include/dev/ic/esp.h: No such file or directory >> = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libc+= +/l >> ibc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >> = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/l= ib/ >> libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>=20 >> Again the tmp/usr/lib/libc++.so path but the content has = /lib/libc++.so.1 . >>=20 >> Again it was a META_MODE build. >>=20 >> https://ci.freebsd.org and https://ci.freebsd.org show >> successful builds at this point. >>=20 >>=20 >> It looks like Cy may need to report more about the context >> for the reported build failure. >=20 > It was a NO_CLEAN build. A CLEAN build resolved it. >=20 > There were no mods to this, my prod tree, except for some upcoming = ipfilter=20 > commits intended for the new year. >=20 > One would think a META_MODE build would also fail if NO_CLEAN fails. In the following, the file path of the text was found in comes after the line(s) with the found text in that file: CMD @rm -f libc++.so.1 libc++.so = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.so.1.full.meta CMD install -U -S -C -o root -g wheel -m 444 libc++.ld = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so R 74586 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /_libinstall.meta I expect those suggest that META_MODE tracks the file's status and the status of related files enough --and so it leads to the update that NO_CLEAN did not do. Overall you basically reported that NO_CLEAN did not do the rm of libc++.so --so it apparently did not do some of the related lib/libc++/libc++.so.1.full.meta activity that involved that remove. Given the removal happened under META_MODE, it also lead to the install happening to re-create the file. Such is what I would expect (or hope) for META_MODE use. > Sorry for the late reply. There are other things here that needed some=20= > urgent attention. >=20 No problem. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F2CC835-812C-40F9-9097-B28AD8405737>