Open Atemu opened 3 years ago
I marked this as stale due to inactivity. → More info
Still important to me.
But for our i686-linux
stdenv the default installation path is $out/lib
and no lib32
directory exists in there. That sounds consistent to me; am I missing something?
EDIT: I mean, I can imagine it all changed, but I'd expect that to have quite non-trivial consequences and thus need substantial motivation.
Yeah, I don't think it would be a good idea to change this globally, especially if we only do this for i686-linux
and not other platforms. To emulate what other distros do, I think we would have to build a separate ld specifically for running 32bit applications on a 64bit system, that's different from the ld used on a native 32bit system. Although, I don't think that's a good solution either, since we would have to rebuild everything for both variants. I think we should just keep the current behaviour and workaround this in the projects where this is a problem.
Luckily, for vkBasalt & MangoHud, vulkan-loader
now allows defining multiple layer files with the same name, but different architectures: https://github.com/KhronosGroup/Vulkan-Loader/pull/525. The vkBasalt package already assumes this works, but vulkan-loader
(and every other vulkan library) still needs to be updated in nixpkgs. I'm actually testing this out the upgrade right now, and I'll be submitting a PR shortly.
There is some "multi-lib stdenv" but I don't know the status:
{
# A stdenv capable of building 32-bit binaries. On x86_64-linux,
# it uses GCC compiled with multilib support; on i686-linux, it's
# just the plain stdenv.
stdenv_32bit = lowPrio (if stdenv.hostPlatform.is32bit then stdenv else multiStdenv);
}
@vcunat Hmm, I think the 32bit ld in "multi-lib stdenv" might still expand $LIB
to lib, since it looks like it just creates a wrapper that combines the two builds: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/multi.nix, but I will try it out.
I marked this as stale due to inactivity. → More info
Describe the bug A clear and concise description of what the bug is.
Dynamic linking tokens can be put in the library path and ld.so is supposed to fill it in according to the executable's arch.
From to the manpage:
To Reproduce Steps to reproduce the behavior:
$LIB
in place oflib
orlib32
in the library pathlib
, notlib32
This can be observed by looking at the paths in the log of
LD_DEBUG=libs
or infering it fromLD_PRELOAD
error messages:(I'm sure there are better methods.)
Expected behavior A clear and concise description of what you expected to happen.
This would be expected behaviour with 64bit executables but with 32bit ones, it should be the other way around:
Screenshots If applicable, add screenshots to help explain your problem.
Additional context Add any other context about the problem here.
This popped up in https://github.com/NixOS/nixpkgs/issues/84686 while trying to update to 0.5.1 where Mangohud switched to a loading mechanism which relies on dynamic linking tokens.
Notify maintainers
@vcunat @jtojnar @edolstra @Ma27
Metadata Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.Maintainer information: