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

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 .

> <snip>
> --- all_subdir_lib/libclang_rt ---
> ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside
> /usr/obj/usr/src/amd64.amd64/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)
> 
> make[2]: stopped in /usr/src
> </snip>
> 
> The stated file is indeed not present, and resides in .../tmp/lib
> instead of .../tmp/usr/lib.

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 appears that the .so linker script
> should either be patched (to point to /lib instead of /usr/lib) or
> a symlink for the .so.1 file should be created.
> (at least the corresponding c++ command line doesn't indicate
> anything to the contrary of that afaik)
> 
> I don't know when this problem was introduced and it might be the
> case that this bootstrapping problem only occurs when the "outside
> system" (in this case FreeBSD 13.1) has an older version of clang.

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.

> (as I'm not really sure when the bootstrapping process actually
> kicks in, as it appears to have omitted building a linker when it
> detected that the current one is recent enough/matches)
> It might also be that case that this is just the result of a
> missing dependency, which messes with parallel building, idk...

Looks to me like whatever vintage/variant of 13.1 it was did
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.

===
Mark Millard
marklmi at yahoo.com