Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib

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.

Sorry for the late reply. There are other things here that needed some 
urgent attention.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

	The need of the many outweighs the greed of the few.