maximum file size exceeded on a library

[nagisa]

Describe the bug

Running patchelf --set-rpath on a certain nvidia binary library will make patchelf output maximum file size exceeded.

Steps To Reproduce

patchelf --set-rpath '$ORIGIN' libcudnn_etc.so.8.0.0
maximum file size exceeded

The attached library has been xz-compressed, and its filename changed to fit github's filename requirements.
libcudnn_etc.so.8.0.0.gz

Decompress with

mv libcudnn_etc.so.8.0.0.gz libcudnn_etc.so.8.0.0.xz
xz -d libcudnn_etc.so.8.0.0.xz

Expected behavior

I expected patchelf to just work.

patchelf --version output

patchelf 0.9 and patchelf 0.10 (both as packaged in NixOS)

Additional context

The library is aarch64 one.

[domenkozar]

Could you try with master branch?

[nagisa]

Reproducible with master:

$ nix shell --experimental-features 'nix-command flakes' github:NixOS/patchelf -c patchelf --set-rpath '$ORIGIN' libcudnn_etc.so
patchelf: maximum file size exceeded

[matthewbauer]

I'm seeing a similar thing, this time with x86_64 on libcudnn_cnn_infer.so.8.0.2 in NixOS/nixpkgs#95727.

[domenkozar]

Duplicates #62 and #88

For aarch64 this was fixed in 0.12

[tobiasBora]

@matthewbauer Did you manage to solve the issue? I have exactly the same problem on libcudnn_cnn_infer.so.8 trying to write a derivation for DaVinci Resolve. For reference, I using this derivation:

{ stdenv, mkDerivation, unzip, autoPatchelfHook, wrapQtAppsHook, libarchive, gtk2, qtbase, gstreamer, libpng12, ocl-icd, openssl, opencl-headers, alsaLib, libXtst, libXdamage, libGLU, gnome3, libXxf86vm,
  cudatoolkit, addOpenGLRunpath }:

mkDerivation rec {
  version = "16.2.7";
  name = "DaVinci_Resolve_${version}";

  src = ./DaVinci_Resolve_16.2.7_Linux.zip;

  unpackPhase = ''
    unzip $src
    # Folder to extract the .run ISO image to
    mkdir extracted
    # bsdtar comes from libarchive
    bsdtar x -f DaVinci_Resolve_${version}_Linux.run -C extracted
    export sourceRoot=extracted
  '';

  
  nativeBuildInputs = [
    unzip
    libarchive # to get bsdtar
    autoPatchelfHook # Will through errors if a lib can't be find, then use nix-locate -1 libasound.so.2 for example to get the name of the lib to include
    wrapQtAppsHook # To wrap Qt apps
    addOpenGLRunpath
  ];

  buildInputs = [
    alsaLib
    gtk2
    gstreamer
    libpng12
    ocl-icd
    openssl
    qtbase
    alsaLib
    libXtst
    libXdamage
    libGLU
    cudatoolkit
    gnome3.librsvg
    libXxf86vm
  ];
  
 
  installPhase= ''
    mkdir -p $out
    cp -r * $out
  '';

  # Make sure the build does not fail on missing `libcuda.so.1` as it's provided at runtime.
  # Not sure if there is a better option...
  autoPatchelfIgnoreMissingDeps = false;

  # Seems to be the method used by blender & co to provide libcuda.so.1 at runtime
  postFixup = ''
    for program in $out/bin/*; do
      isELF "$program" || continue
      addOpenGLRunpath "$program"
    done
  '';

  meta = {
    description = "DaVinci Resolve";
    homepage = https://;
    license = stdenv.lib.licenses.unfree;
    maintainers = [ stdenv.lib.maintainers.tobiasBora ];
    platforms = stdenv.lib.platforms.linux;
  };
}

and build with:

nix-build -E "let pkgs = import <nixpkgs> {}; in pkgs.libsForQt5.callPackage ./derivation.nix {}"

[mkolod]

I'm getting the same issue, also with the same library, with x86_64 on patchelf master as of today (last commit: 47dc18d0e5c1ff24f815177927940c294b1fde76).

[mkolod]

The fix is to change 32 to 64 here and then rebuild patchelf. Tried on 47dc18d0e5c1ff24f815177927940c294b1fde76.

[tfmoraes]

@tobiasBora have you managed to fix this problem with Davinci Resolve?

[tobiasBora]

No, but to be honest I didn't spent more time on it. The solution proposed by mkolod may be a temporary solution, but I guess it will increase the size of all packages, and also we won't have any guarantee that later we won't find a file that do not need a still biger value. Also, not sure how to enable it quickly on a per package process, I guess we could include a different input that patches the patchelf code? There is no proper way of solving this issue?

[tfmoraes]

I managed to create a Davinci Resolve derivation. I posted it here @tobiasBora.

[tdp2110]

(Also hit this issue on cudnn libs today) I'm a bit confused by the code referenced @mkolod referenced here. There are simpler ways to read files in C++ which don't involve the read, open syscalls, or pre-reserving a buffer. Maybe I'll submit a patch and see what the maintainers think.

[jue89]

I just hit the same error message ... for details see: NixOS/nixpkgs#94032 (comment)