Re: git: 65f28f63a73d - main - tools/build: Create toolchain symlinks for non-absolute compiler/linker
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.