From d151f99d0f0c460b2f5344c58a4e1b759b7dffcd Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich Date: Sat, 6 Dec 2025 21:13:37 +0000 Subject: [PATCH] build-fhsenv-bubblewrap: fix /usr/lib to point to /usr/lib32 on i686-linux Without the change buildFHSEnv on "i686-linux" tries to link /usr/lib to /usr/lib64. This causes problems for packages that assume that /usr/lib contains actual libraries (like vanilla gcc build). On "i686-linux" most libraries go to /usr/lib32. /usr/lib64 is virtually empty (it should be completely, but let's leave it for another day). As a result /usr/lib contains none of the expected libraries and FHS programs fails to find them. THe change makes "lib" dependent on `system` target. Tested the change by building `gcc` on `x86_64-linux` and `i686-linux`. Both still pass the build. --- .../build-fhsenv-bubblewrap/buildFHSEnv.nix | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/pkgs/build-support/build-fhsenv-bubblewrap/buildFHSEnv.nix b/pkgs/build-support/build-fhsenv-bubblewrap/buildFHSEnv.nix index b85cd9a04a6c..8bfd18461a18 100644 --- a/pkgs/build-support/build-fhsenv-bubblewrap/buildFHSEnv.nix +++ b/pkgs/build-support/build-fhsenv-bubblewrap/buildFHSEnv.nix @@ -46,6 +46,13 @@ let # "use of glibc_multi is only supported on x86_64-linux" isMultiBuild = multiArch && stdenv.system == "x86_64-linux"; + # What should lib be linked to: lib32 or lib64? + defaultLib = + { + "i686-linux" = "lib32"; + "x86_64-linux" = "lib64"; + } + .${stdenv.system} or (throw "Please expand list of system with defaultLib for '${stdenv.system}'"); # list of packages (usually programs) which match the host's architecture # (which includes stuff from multiPkgs) @@ -229,7 +236,7 @@ let ln -s /usr/lib $out/lib ln -s /usr/lib32 $out/lib32 ln -s /usr/lib64 $out/lib64 - ln -s /usr/lib64 $out/usr/lib + ln -s /usr/${defaultLib} $out/usr/lib ln -s /usr/libexec $out/libexec # symlink 32-bit ld-linux so it's visible in /lib