Possibility of symlinking libstdc++ under some circumstances

[frankier]

Many people are in practice deleting at least libstdc++.so from their Julia install and replacing it with a symlink to their system libstdc++. The reason stems from JuliaGL/GLFW.jl#198 . We can have a call chain Julia -> GLFW.jl -> OpenGL library -> OpenGL driver -> Julia's bundled libstdc++, but the bundled libstdc++ is too old and so missing symbols the OpenGL driver expects to find (even if it doesn't use them?).

As far as I know, there are only, two solutions 1) somehow package all driver code with Julia and pick the right drivers and so on, so we get stuff built with the correct libstdc++ (seems undesirable/Herculean task for marginal gain) 2) replace some bundled libraries with system libraries under some circumstances (at least libstdc+++ -- but I guess it's possible a larger whitelist could be needed or useful under some circumstances).

I propose making what seems to be a fairly standard workaround a supported part of the Julia installation process by adding a flag, --use-system-libstdc++=no,auto,force. The default would be no, at least to begin with since it's a bit heavy handed and there could be unintended consequences -- we can see what general community feedback is. force would just blindly link the system libstdc++ at the user's own risk. The auto behaviour would be to check the version of the bundled libstdc++ is older than the system one, and if so replace it with a symlink to the system one.

This does not completely solve the problem. A user who had an old libstdc++ when installing a version of Julia could later update their system and end up with a newer libstdc++, which would not be used by Julia. One possibility would be to have a juliaup-system-update-hook command, which would check for any Julia installations which were created with auto, and rerun the auto logical after the update. It would be up to the user to arrange for this to be called after a system update e.g. in Debian you can add /etc/apt/apt.conf.d/1000juliauphook with DPkg::Post-Invoke-Success {"touch /var/lib/apt/post-update-stamp"; };. Users could be hinted to install this when using --use-system-libstdc++=auto.

[DilumAluthge]

I don't think we should be adding a lot of nonstandard stuff to Juliaup. Juliaup's job should really only be to download and run the official Julia binaries, unmodified.

It's fine if users want to apply these workarounds themselves, but I don't think we should add them to Juliaup.

[frankier]

I can see the concern about scope creep of juliaup, but as I see it, juliaup is trying to improve the usability of Julia. Say x% of Julia users want to use e.g. OpenGL plotting and either want to use a new version of Julia on a Linux distribution with OpenGL drivers linked to a newer libstdc++ -- or even an older Linux distro with an even older version of Julia. Those x% of people all see an error message, search for it, and hopefully manage to find and implement the workaround. However, they would reasonably have the perception that this is rather poor usability wise. All those x% have had to implement this workaround rather than whatever they were originally trying to accomplish.

Is there an alternative path to improving the usability here? Which project is better placed deal with this than juliaup?

[frankier]

Closing as per JuliaLang/julia#34276 and JuliaCI/julia-buildkite#205