electron_bin variants still have issues finding lib*GL

[yu-re-ka]

Describe the bug

#269104 / #269345 is still present in the electron*-bin variants

Would need a fix similar to vscode/spotify/... #272028

This only really affects users of EOL electron versions, since everything recent is using the source-built electron derivation by default on Linux (and I have no idea if/how Mac OS is affected by this issue, probably not).

Steps To Reproduce

Steps to reproduce the behavior:

1. nix run electron_27-bin
2. Observe errors: ANGLE Display::initialize error 12289: Could not dlopen libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory

CC the electron-bin maintainers @travisbhartwell @manveru @prusnak

[Kiskae]

This appears to be triggered by the libANGLE library:
https://github.com/google/angle/blob/f57ab75f096956a7b803b249bbafecfc89995456/src/libANGLE/renderer/gl/glx/FunctionsGLX.cpp#L147-L152

Specifically I believe the file libexec/electron/libGLESv2.so needs to have its rpath patched so it can find the following libraries:

❯ readelf -p .rodata /nix/store/a1fi8rf3n8mkccnn38cw6nfq9xjj6jx1-electron-27.0.0/libexec/electron/libGLESv2.so | grep "\.so"
  [ 12117]  libvulkan.so
  [ 12124]  libpci.so
  [ 37781]  libpci.so.3
  [ 3849a]  libvulkan.so.1
  [ 384a9]  libGL.so.1
  [ 384b4]  libEGL.so.1
  [ 4cd9d]  Could not dlopen libGL.so.1: 

One thing I noticed is that that LD_DEBUG doesn't show any search path before init for these libraries. That leads me to believe that electron dynamically resolves the absolute path before calling dlload, ignoring any environment variables or rpath changes in the process.

We can fix this by either ensuring all the libraries included are properly patched, or perhaps replacing them with symlinks to nix-specific loaders like libglvnd or libvulkan. But I'm not sure if these libraries include additional functionality that chrome depends on.

[Kiskae]

Confirmed behavior with ltrace:

[pid 2901300] electron->dlopen("libpci.so.3", 1)                                                                                                              = 0x1c4c00064000
[pid 2901300] electron->dlopen("/nix/store/a1fi8rf3n8mkccnn38cw6nfq9xjj6jx1-electron-27.0.0/libexec/electron/libGLESv2.so", 1)                                = 0x1c4c00020c00
[pid 2901300] electron->dlopen("/nix/store/a1fi8rf3n8mkccnn38cw6nfq9xjj6jx1-electron-27.0.0/libexec/electron/libEGL.so", 1)                                   = 0x1c4c00021200
[pid 2901300] libEGL.so->dlopen("/nix/store/a1fi8rf3n8mkccnn38cw6nfq9xjj6jx1-electron-27.0.0/libexec/electron/libGLESv2.so", 2)                               = 0x1c4c00020c00
[pid 2901300] electron->dlopen("/nix/store/a1fi8rf3n8mkccnn38cw6nfq9xjj6jx1-electron-27.0.0/libexec/electron/libvulkan.so", 2)                                = nil
[pid 2901300] electron->dlopen("/nix/store/a1fi8rf3n8mkccnn38cw6nfq9xjj6jx1-electron-27.0.0/libexec/electron/libvulkan.so.1", 2)                              = 0x1c4c00021800
[pid 2901300] electron->dlopen("libX11.so.6", 1)                                                                                                              = 0x7fb74982b060
[pid 2901300] electron->dlopen("libX11-xcb.so.1", 1)                                                                                                          = 0x1c4c00064500
[pid 2901300] libGLESv2.so->dlopen("libGL.so.1", 2)                                                                                                           = nil

[yu-re-ka]

Note what @lilyinstarlight wrote on the issues/PRs linked above:

It was working by accident before, because cairo lib pulled in libEGL so dlopen didn't need to search rpath when called in libGLESv2. The fix should be to add the rpath to the libGLESv2 lib in the chromium-unwrapped derivation postFixup rather than on the chromium executable itself. I'm preparing a PR now