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).

0 files changed, 0 insertions, 0 deletions