Loading
zoom-us (x86-64): don't touch the core `zoom` binary
Without the commit at hand, zoom-us stops working and instead simply maxes out RAM when updated from version 6.2.11.5069 to version 6.3.0.5527 . https://github.com/NixOS/nixpkgs/issues/371488 Some experimenting yielded these observations regarding newer (problematic) zoom-us versions on NixOS: * They still work if started via flatpak (which creates a virtual FHS-compatible environment) * They still work if started with `buildFHSEnv` with all libraries provided in `multiPkgs`. * They still work if the unmodified zoom binary is started by manually invoking the `ld-linux` elf interpreter. However, this again requires that libraries are available via `LD_PRELOAD_PATH`. It seems very much that the `patchelf --set-interpreter` call on the `zoom` binary breaks something inside the binary. The commit at hand removes `zoom` from the list of binaries that are to be patched. To ensure that program can still be executed, the `makeWrapper` call (which is already there to wrap `zoom`) is extended such that is explicitely uses the elf interpreter. Unfortunatelly, when zoom tries to find its data files (e.g. ring tones), it determines its data directory by looking at `/proc/self/exe`. If we start zoom by calling the elf interpreter, `/proc/self/exe` acutally points to that interpreter. The only solution is to copy the interpreter into the zoom data directory (a symlink isn't enough here).