fix(toolchain): pass -L as well as an rpath for a toolchain outside /usr
Inside the Flatpak the bundled toolchain compiled every bootstrap object, then glslang's configure failed its test link with `unable to find library -lc++`. clang searches its per-target runtime directory (lib/<triple>) and the system library paths for libc++, not <prefix>/lib, so with the classic layout a toolchain outside /usr needs the search path spelled out, just as its loader needs the rpath. LibcxxLinkFlags and build.sh now emit both, the same pair an explicit CRAFTER_BUILD_LIBCXX_DIR already got. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
parent
a72d18eeab
commit
d22a8603df
4 changed files with 25 additions and 19 deletions
|
|
@ -44,10 +44,12 @@ export namespace Crafter {
|
|||
|
||||
// Flags for compiling against libcxxDir; empty without one.
|
||||
std::string LibcxxCompileFlags() const;
|
||||
// Flags for linking against the libc++ the compiler will use: an
|
||||
// rpath into the prefix when that is not the system one (a bundled
|
||||
// toolchain's libc++.so.1 is not on the loader's default path), plus
|
||||
// -L and an rpath for an explicit libcxxDir.
|
||||
// Flags for linking against the libc++ the compiler will use: a -L
|
||||
// and an rpath for <prefix>/lib when the prefix is not the system one
|
||||
// (clang searches only its per-target runtime directory and the
|
||||
// system paths, and a bundled toolchain's libc++.so.1 is on neither
|
||||
// the linker's nor the loader's default path), or for an explicit
|
||||
// libcxxDir.
|
||||
std::string LibcxxLinkFlags() const;
|
||||
// Names this toolchain for cache directory names: the clang version
|
||||
// followed by a hash of what decides which headers and libraries a
|
||||
|
|
|
|||
Loading…
Reference in a new issue