Re: all_subdir_lib/libclang_rt build failure (libc++ ld error)

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