Re: git: 65f28f63a73d - main - tools/build: Create toolchain symlinks for non-absolute compiler/linker

From: Mark Johnston <markj_at_freebsd.org>
Date: Sun, 30 Jul 2023 22:50:36 UTC
On Thu, Jul 27, 2023 at 04:12:02AM +0000, Jessica Clarke wrote:
> The branch main has been updated by jrtc27:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=65f28f63a73d3371d9d724a2018be6d1ada0d3e0
> 
> commit 65f28f63a73d3371d9d724a2018be6d1ada0d3e0
> Author:     Jessica Clarke <jrtc27@FreeBSD.org>
> AuthorDate: 2023-07-27 04:10:47 +0000
> Commit:     Jessica Clarke <jrtc27@FreeBSD.org>
> CommitDate: 2023-07-27 04:10:47 +0000
> 
>     tools/build: Create toolchain symlinks for non-absolute compiler/linker
>     
>     If any of the toolchain variables are not absolute then we need to
>     create a symlink in WORLDTMP/legacy/bin in order to make them available
>     during a BUILD_WITH_STRICT_TMPPATH build.

This commit appears to break a 13.0-RELEASE jail's ability to build
world from the main branch.  Specifically, while building clang during
the cross tools stage, lib/Support/BLAKE3/blake3.c can't be compiled
because immintrin.h isn't found.

The host compiler is clang 11.0.1.  Some experimentation shows that this
version of clang, when invoked using the absolute path of the symlink in
tmp/legacy/usr/bin created as of this commit, does not search
/usr/lib/clang/11.0.1 for immintrin.h.  It only looks in /usr/include.
If I invoke clang using a relative path to the symlink, it finds
immintrin.h.  Newer versions of LLVM don't have this (buggy?) behaviour,
they search their resource directory in either case.

Is this a bug in the commit, or does this just mean that I need to
upgrade my jail?  I'm not sure what guarantees we provide with respect
to origin versions of source upgrades.