Remove preferred GCC runtime library symlinks from lib.

[carlocab]

Provide a detailed description of the proposed feature

gcc@5 installs symlinks to the runtime libraries in lib/"gcc/5" to lib:

      # Add symlinks for libgcc, libgomp, libquadmath and libstdc++ so that bottles
      # built in CI can find these libraries when using brewed gcc@5
      if OS.linux?
        lib.install_symlink lib/"gcc/#{version_suffix}/libgcc_s.so"
        lib.install_symlink lib/"gcc/#{version_suffix}/libgcc_s.a"
        lib.install_symlink lib/"gcc/#{version_suffix}/libgcc_s.so.1"
        lib.install_symlink lib/"gcc/#{version_suffix}/libgomp.so"
        lib.install_symlink lib/"gcc/#{version_suffix}/libgomp.a"
        lib.install_symlink lib/"gcc/#{version_suffix}/libgomp.so.1"
        lib.install_symlink lib/"gcc/#{version_suffix}/libquadmath.so"
        lib.install_symlink lib/"gcc/#{version_suffix}/libquadmath.a"
        lib.install_symlink lib/"gcc/#{version_suffix}/libquadmath.so.0"
        lib.install_symlink lib/"gcc/#{version_suffix}/libstdc++.so"
        lib.install_symlink lib/"gcc/#{version_suffix}/libstdc++.a"
        lib.install_symlink lib/"gcc/#{version_suffix}/libstdc++.so.6"
      end

Now that our preferred GCC is going to be gcc@11, these symlinks are being moved to gcc@11.

Instead of needing these symlinks, we should get rid of them.

What is the motivation for the feature?

This follows from the discussion in #13619.

Not having those symlinks would actually be great because it would permanently solve the somewhat recurring issue of those links breaking things, and bring us one step closer to dropping the RPATH to $HOMEBREW_PREFIX/lib entirely, which we've all agreed is a good idea in the long run.

#13619 (comment)

These symlinks require special handling that would be nice to avoid, and cause random problems for users.

How will the feature be relevant to at least 90% of Homebrew users?

It'll make maintainers' lives easier, which may or may not impact 90% of Homebrew users. It'll also cause fewer problems for users with existing GCCs that are older than our preferred one, which would be a substantial share of existing Linux users when we switch to Ubuntu 22.04.

What alternatives to the feature have been considered?

Keeping them?

[Bo98]

This feels like something unversioned gcc should do.

[carlocab]

I'd like to avoid creating these at all, but, yes, these should be unversioned gcc if we have to.

If/when enough bottles are rebuilt with #13659, we could even probably just always use unversioned gcc whenever we need the runtime libraries. At least, until upstream decide to bump SO versions without providing a compat layer (e.g. current libgcc_s.1).

[danielnachun]

I'm in agreement with all of the above - ideally we shouldn't even have -L$HOMEBREW_PREFIX/lib or -Wl,-rpath,$HOMEBREW_PREFIX in our LDFLAGS on any OS, as these links can disappear with brew unlink. I do recall some other random breakages happening when we tried to remove those flags when building with brewed GCC so there may be some other issues besides this that are needed to fully ignore HOMEBREW_PREFIX/lib. But this is a really good start!

[MikeMcQuaid]

Closing as there's been no progress here in a year and I don't think it's worth keeping this open indefinitely.