Hello,
On 21.12.22 01:24, Mark Millard wrote:
Alain Zscheile <zseri.devel+fbsd_at_ytrizja.de> wrote on
Date: Tue, 20 Dec 2022 23:12:40 UTC :
I encountered a build failure while trying to build fbsd'
src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
That commit is from main:
• git: ae521fda895f - main - stress2: Added link to problem found Peter
Holm
with `make -j4 buildworld` on an FreeBSD 13.1 system.
So this was some 13.1 variant building at ae521fda895f of
main [so: 14]. That was not obvious on a first read of the
report. Sort of a self-hosted version upgrade cross-build.
For reference (example local installs):
# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \; | grep -v
lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/lib/libc++.so.1
Note that only main has main-amd64-poud-bulk_a/lib/libc++.so.1
and it does not have a main-amd64-poud-bulk_a/usr/lib/libc++.so.1 .
As for lib32:
# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \; | grep lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/usr/lib32/libc++.so.1
So all 3 have *-amd64-poud-bulk_a/usr/lib32/libc++.so.1 and none
have a *-amd64-poud-bulk_a/lib32/libc++.so.1 .
tmp/lib/libc++.so.1 would be a main [so: 14] style path.
tmp/usr/lib/libc++.so.1 would be a 13.1 style path.
The build appears to have which type of context applies
confused.
It is not clang that is the issue, it is that FreeBSD changed
the path used for libc++.so.1 . (main avoids needing more
mounts already being actie place when libc++.so.1 is used in
some common configurations, usr/lib/ not being available yet.
thanks for the explanation.
Looks to me like whatever vintage/variant of 13.1 it was did
"vintage" I upgraded to the latest stable/13 commit before
attempting the jump to main.
not yet(?) have logic for making sure that it provides for
builds of main [so: 14] that have the new libc++.so.1 style
path. Nor did the main materials have logic to make it work
when built from an older context, such as a 13.1 context.
At least one of the two must happen to allow 13.1 to build
a 14. Having main [so: 14] deal with it, if possible, could
possibly also deal with 13.0 vintages/variants without
adjusting 13.0 materials.
To somewhat fix it I ran: `make cleanworld`,
then reran `make -j4 buildworld`, while that was in progress
I created a symlink from .../tmp/usr/lib/libc++.so.1 to
`../../lib/libc++.so.` which resulted in a successfully finishing
build.
Regards,
Alain Zscheile
