Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib
Date: Fri, 31 Dec 2021 03:15:51 UTC
> On 2021-Dec-30, at 15:14, Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > In message <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com>, Mark Millard > write > s: >> On 2021-Dec-30, at 11:52, Mark Millard <marklmi@yahoo.com> wrote: >> >>>> This commit results in a different error. >>>> >>>> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2 >> : >>>> 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 >>>> invocation) >>>> *** [libclang_rt.asan-x86_64.so.full] Error code 1 >>>> >>>> make[6]: stopped in /opt/src/git-src/lib/libclang_rt/asan_dynamic >>> >>> 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: >>> >>> # 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 >> ) >>> /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 >> 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/lib >> /libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>> >>> That has /lib/libc++.so.1 (outside lib32 materials). >>> >>> But it also has: /tmp/usr/lib/libc++.so and is that a problem? >>> >>> And, checking on when the files were modified: >>> >>> # 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 >> 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 >>> >>> So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been >>> updated. >>> >>> I used META_MODE. >>> >>> 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. >>> >>> 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. >> >> So I've now looked at a build (not installed) that was done on: >> >> # 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 >> >> which is before the original attempt to move libc++.so.1 . It shows: >> >> # 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/lib/ >> libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >> >> Again the tmp/usr/lib/libc++.so path but the content has /lib/libc++.so.1 . >> >> Again it was a META_MODE build. >> >> https://ci.freebsd.org and https://ci.freebsd.org show >> successful builds at this point. >> >> >> It looks like Cy may need to report more about the context >> for the reported build failure. > > It was a NO_CLEAN build. A CLEAN build resolved it. > > There were no mods to this, my prod tree, except for some upcoming ipfilter > commits intended for the new year. > > 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/lib/libc++.so R 74586 /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/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 > urgent attention. > No problem. === Mark Millard marklmi at yahoo.com