On 2021-Dec-30, at 11:52, Mark Millard <mark...@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/tmp/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/lib/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/GENERIC-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/usr/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-nodbg-clang/usr/main-src/amd64.amd64/` > grep: > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-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/usr/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-amd64-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-amd64-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-amd64-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-amd64-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-254e4e5b77d7-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-CA72 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/usr/include/dev/ic/esp.h: No such file or directory /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libc++/libc++.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. === Mark Millard marklmi at yahoo.com
