Turns out Rider was previously relying on having libstdc++ in
LD_LIBRARY_PATH, because the binaries were not patched properly.
Rewrite the patching to use autoPatchelf similar to CLion so that the
RPATH of the binaries are adjusted. While at it also patch all the
binaries in the dotCommon and dotTrace plugins. Those seem to need zlib
and fontconfig which were completely missing before (they are probably
only called when using certain functionality of the IDE).
icu doesn't actually seem to be needed (autoPatchelf does not complain
that it's missing) and the IDE starts fine without it, so drop it for
now.
Most of the libraries listed in the LD_LIBRARY_PATH for the Jetbrains
IDEs are loaded indirectly using JNA in Java code, e.g.
myLibNotify = Native.load("libnotify.so.4", LibNotify.class); [1]
private val library = Native.load("secret-1", SecretLibrary::class.java) [2]
In this case the typical patching mechanism with Nix does not work
because JNA does the library lookup at runtime with its own mechanism.
However, to avoid causing ABI conflicts when using Nix in the terminal
of the IDE it's better to avoid using LD_LIBRARY_PATH. JNA also looks
for a "jna.library.path" Java system property when looking for libraries.
Generate that property with the needed paths instead and append it to
the vmopts file so that the property is applied when starting the IDE.
With this the libraries only become available for the IDE and do not
leak into terminals opened within the IDE context.
[1]: c0a703267a/platform/platform-impl/src/com/intellij/ui/LibNotifyWrapper.java (L40)
[2]: c0a703267a/platform/credential-store/src/linuxSecretLibrary.kt (L38)
Most of the libraries listed in the LD_LIBRARY_PATH for the Jetbrains
IDEs are loaded indirectly using JNA in Java code, e.g.
myLibNotify = Native.load("libnotify.so.4", LibNotify.class); [1]
private val library = Native.load("secret-1", SecretLibrary::class.java) [2]
In this case the typical patching mechanism with Nix does not work
because JNA does the library lookup at runtime with its own mechanism.
However, there is one outlier: stdenv.cc.cc.lib is also added to the
LD_LIBRARY_PATH for libstdc++.so.6 because it is reportedly needed
for some "internals". It does not make sense to access libstdc++
from Java code so it feels like this one was added to work around
some native library or executable that should be patched instead
of using LD_LIBRARY_PATH.
Unfortunately, having libstdc++ in LD_LIBRARY_PATH can also easily
cause ABI conflicts. This is because this variable is inherited into
terminals opened within the IDE. Using a Nix environment there with
different versions of libstdc++ easily causes errors such as
libstdc++.so.6: version `GLIBCXX_3.4.29' not found
Most of the IDEs work just fine without having libstdc++ in
LD_LIBRARY_PATH. Since it's not really clear why it has to be in
there let's just drop it to avoid the ABI conflicts.
[1]: c0a703267a/platform/platform-impl/src/com/intellij/ui/LibNotifyWrapper.java (L40)
[2]: c0a703267a/platform/credential-store/src/linuxSecretLibrary.kt (L38)
* jetbrains.rust-rover: fix darwin install
JetBrains doesn't guarantee that the macOS app will be called
`${product}.app` so I modified the installPhase to copy *.app instead
of ${product}.app, which fails on file does not exist for Rust Rover,
which is `RustRover 2023.2 EAP.app`
I've tested with some other JetBrains apps on darwin aarch64 and they
continue to build as expected.
