Date: Wed, 21 Dec 2022 14:41:07 +0100 From: Alain Zscheile <zseri.devel+fbsd@ytrizja.de> To: freebsd-current@FreeBSD.org Subject: Re: all_subdir_lib/libclang_rt build failure (libc++ ld error) Message-ID: <f2d216cf-dff4-033f-0d89-8831ed23952a@ytrizja.de> In-Reply-To: <EB16D73A-3B10-4F5D-846C-D6EFC75FF85F@yahoo.com> References: <EB16D73A-3B10-4F5D-846C-D6EFC75FF85F.ref@yahoo.com> <EB16D73A-3B10-4F5D-846C-D6EFC75FF85F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f2d216cf-dff4-033f-0d89-8831ed23952a>