Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib
> On 2021-Dec-30, at 15:14, Cy Schubert wrote: > > In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard > write > s: >> On 2021-Dec-30, at 11:52, Mark Millard 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.
Re: recent commit breaks buildkernel
On Thu, 30 Dec 2021 at 02:41, Gary Jennejohn wrote: > > commit ff3a85d32411cdd7894f932b1d3d7ce01ec7a648 breaks buildkernel > if options INET6 is not in the kernel config file. Thanks for the report, this should be fixed by 818952c638a7. A build without INET appears to be broken for other reasons at the moment; I'll try to take a look at that.
Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib
In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard write s: > On 2021-Dec-30, at 11:52, Mark Millard 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 t
Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?]
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. Background: /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 and: lrwxr-xr-x 1 root wheel23 Dec 29 13:17:01 2021 /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 Why did libc++.so.1 not get a: /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 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. I have finally reproduced Cy's build error locally and am testing my fix. If it works I'll commit it. -- John Baldwin
Re: Problems compiling kernel
> Dear all, > > on a system updated yesterday I get > > tuexen_at_head:~/freebsd-src % git branch > * main > tuexen_at_head:~/freebsd-src % git pull > Already up to date. > tuexen_at_head:~/freebsd-src % uname -a > FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: > Thu Dec 30 11:33:16 CET 2021 > root_at_head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP amd64 > tuexen_at_head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP > ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: > warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: > Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. > > make: stopped in /usr/home/tuexen/freebsd-src > tuexen_at_head:~/freebsd-src % > > any idea what I did wrong and how to fix it? The problem is in FreeeBSD itself from: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib Ed Maste (2021-Dec-29) until the revert: git: b6f7942cbcbd - main - Revert "Move libc++ from /usr/lib to /lib" Ed Maste or, the fixed commit, if you want /lib/libc++.so.1 : git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib Dimitry Andric (2021-Dec-30) 6b1c5775d1c2 did not actually cause /lib/libc++.so.1 to be installed but still put it at /usr/lib/libc++.so.1 . But its delete-old-libs did remove /usr/lib/libc++.so.1 . (I suffered this too.) A solution is to find libc++.so.1 in your build tree and to copy it to one of the two places (old or new). So, for example: .../amd64.amd64/lib/libc++/libc++.so.1 or, may be: .../amd64.amd64/tmp/lib/libc++.so.1 Some old trees used for chroot use or the like can also be a source for doing such a copy. (That is what I did.) There will likely be another commit making it nicer for NO_CLEAN style builds. 5e6a2d6eb220 is okay for META_MODE builds or complete rebuilds. I also wonder if they will create a: /usr/lib/libc++.so -> ../../lib/libc++.so.1 or not, analogous to the existing: /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 === Mark Millard marklmi at yahoo.com
Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?]
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. > > Background: > > /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 > and: > lrwxr-xr-x 1 root wheel23 Dec 29 13:17:01 2021 /usr/lib/libcxxrt.so > -> ../../lib/libcxxrt.so.1 > > Why did libc++.so.1 not get a: > > /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 > ? Why is it that only libcxxrt.so.1 has such? > > Seems odd to me that the structure of things would > be this different between libcxxrt.so.1 and > libc++.so.1 . > === Mark Millard marklmi at yahoo.com
Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?]
This asks a question in a different direction that my prior reports about my builds vs. Cy's reported build. Background: /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 and: lrwxr-xr-x 1 root wheel23 Dec 29 13:17:01 2021 /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 Why did libc++.so.1 not get a: /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ? Why is it that only libcxxrt.so.1 has such? Seems odd to me that the structure of things would be this different between libcxxrt.so.1 and libc++.so.1 . === Mark Millard marklmi at yahoo.com
Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib
On 2021-Dec-30, at 11:52, Mark Millard 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
Re: Problems compiling kernel
> On 30. Dec 2021, at 20:42, Konstantin Belousov wrote: > > On Thu, Dec 30, 2021 at 08:33:09PM +0100, tue...@freebsd.org wrote: >>> On 30. Dec 2021, at 20:26, Michael Gmelin wrote: >>> >>> This should have been resolved today in >>> https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415 >> I do have that commit locally in the tree... But I can't build world or >> kernel. >> >> Looking for libc++.so.1 I get >> >> tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++* >> -r--r--r-- 1 root wheel 6939492 Dec 30 11:38 /usr/lib/libc++.a >> -r--r--r-- 1 root wheel 68 Jan 28 2021 /usr/lib/libc++.so >> -r--r--r-- 1 root wheel35234 Dec 30 11:38 /usr/lib/libc++experimental.a >> tuexen@head:~/freebsd-src % ls -l /lib/libc++* >> ls: No match. >> tuexen@head:~/freebsd-src % >> >> How can I build a kernel? > > Take libc++.so.1 somewhere, for instance from > https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/base.txz > archive, and put the library to /lib. Works perfectly! Thank you very mich for the quick help! Best regards Michael
Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib
> 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. === Mark Millard marklmi at yahoo.com
Re: Problems compiling kernel
On Thu, Dec 30, 2021 at 08:33:09PM +0100, tue...@freebsd.org wrote: > > On 30. Dec 2021, at 20:26, Michael Gmelin wrote: > > > > This should have been resolved today in > > https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415 > I do have that commit locally in the tree... But I can't build world or > kernel. > > Looking for libc++.so.1 I get > > tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++* > -r--r--r-- 1 root wheel 6939492 Dec 30 11:38 /usr/lib/libc++.a > -r--r--r-- 1 root wheel 68 Jan 28 2021 /usr/lib/libc++.so > -r--r--r-- 1 root wheel35234 Dec 30 11:38 /usr/lib/libc++experimental.a > tuexen@head:~/freebsd-src % ls -l /lib/libc++* > ls: No match. > tuexen@head:~/freebsd-src % > > How can I build a kernel? Take libc++.so.1 somewhere, for instance from https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/base.txz archive, and put the library to /lib.
Re: Problems compiling kernel
> On 30. Dec 2021, at 20:26, Michael Gmelin wrote: > > This should have been resolved today in > https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415 I do have that commit locally in the tree... But I can't build world or kernel. Looking for libc++.so.1 I get tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++* -r--r--r-- 1 root wheel 6939492 Dec 30 11:38 /usr/lib/libc++.a -r--r--r-- 1 root wheel 68 Jan 28 2021 /usr/lib/libc++.so -r--r--r-- 1 root wheel35234 Dec 30 11:38 /usr/lib/libc++experimental.a tuexen@head:~/freebsd-src % ls -l /lib/libc++* ls: No match. tuexen@head:~/freebsd-src % How can I build a kernel? Best regards Michael > > -m > >> On 30. Dec 2021, at 20:17, tue...@freebsd.org wrote: >> >> Dear all, >> >> on a system updated yesterday I get >> >> tuexen@head:~/freebsd-src % git branch >> * main >> tuexen@head:~/freebsd-src % git pull >> Already up to date. >> tuexen@head:~/freebsd-src % uname -a >> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: >> Thu Dec 30 11:33:16 CET 2021 >> root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP amd64 >> tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP >> ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" >> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: >> warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status >> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: >> Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. >> >> make: stopped in /usr/home/tuexen/freebsd-src >> tuexen@head:~/freebsd-src % >> >> any idea what I did wrong and how to fix it? >> >> Thanks for any hints. >> >> Best regards >> Michael
Re: Problems compiling kernel
This should have been resolved today in https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415 -m > On 30. Dec 2021, at 20:17, tue...@freebsd.org wrote: > Dear all, > > on a system updated yesterday I get > > tuexen@head:~/freebsd-src % git branch > * main > tuexen@head:~/freebsd-src % git pull > Already up to date. > tuexen@head:~/freebsd-src % uname -a > FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: > Thu Dec 30 11:33:16 CET 2021 > root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP amd64 > tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP > ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: > warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: > Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. > > make: stopped in /usr/home/tuexen/freebsd-src > tuexen@head:~/freebsd-src % > > any idea what I did wrong and how to fix it? > > Thanks for any hints. > > Best regards > Michael
Problems compiling kernel
Dear all, on a system updated yesterday I get tuexen@head:~/freebsd-src % git branch * main tuexen@head:~/freebsd-src % git pull Already up to date. tuexen@head:~/freebsd-src % uname -a FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: Thu Dec 30 11:33:16 CET 2021 root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP amd64 tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. make: stopped in /usr/home/tuexen/freebsd-src tuexen@head:~/freebsd-src % any idea what I did wrong and how to fix it? Thanks for any hints. Best regards Michael
Re: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib
On 29 Dec 2021, at 22:40, Mark Millard via dev-commits-src-main wrote: > > [Resending with dev-commits-src-m...@freebsd.org CC'd.] > > On 2021-Dec-29, at 13:38, Mark Millard wrote: > > Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing > and rebooting did not put in place a /lib/libc++.so.1 but > delete-old-libs removed the /usr/lib/libc++.so.1 . > > (Luckily my environment has sufficient recent near-redundancy > to recover easily by putting in place a /usr/lib/libc++.so.1 .) This should now be be fixed with: https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415 -Dimitry signature.asc Description: Message signed with OpenPGP
