Carlo Cabrera fa26b5a06d
linux/super: add unversioned GCC lib directory to RPATH
This adds GCC's runtime lib directory to the RPATH of every build on
Linux (unconditionally!).

This is useful for three things:

1. It fixes versioned GCC linkage for formulae that users build from
   source instead of pouring from a bottle. We currently only handle
   bottle installs. See #13633.

2. It helps minimise the GCC dependency explosion. When a formula has a
   Linux-only GCC dependency, then all its dependents that link with
   some GCC runtime library (typically `libstdc++`) must, before this
   change, also adopt a GCC dependency. This is a consequence of our
   injecting GCC's runtime library directory into RPATH only when a
   formula is built with GCC (this is done through the specs file). We
   can avoid the need to do this by always injecting this path instead.

3. This enables us to automatically install Homebrew GCC whenever the
   user's GCC is too old and the formula may need it. Without this
   change, auto-installing GCC is not that useful because formulae that
   need it may not know to look for our GCC, unless the formula already
   happened to be built with our GCC. With this change, these formulae
   will always be able to find our GCC when it is installed. This is
   particularly useful for when we start building with a version of GCC
   that is much closer to the latest than we currently do.

This approach comes with at least two drawbacks:

1. We will see spurious linkage warnings in CI about an undeclared
   dependency with linkage as soon as Homebrew GCC is installed, because
   formulae will link with our GCC instead of the host's. Users will
   also see a similar complaint if they do `brew linkage`.

2. This leans _very_ heavily on GCC delivering backward compatibility of
   their runtime libraries. If they do not, we could see different
   behaviour across different CI runs for the same formula depending on
   whether Homebrew GCC is installed.

It's worth noting that item 3 in the "useful" list above may rely on
features not yet implement in `brew`.
2022-08-06 13:21:18 +08:00
..
2020-10-29 20:39:49 +11:00
2020-10-10 14:59:39 +02:00
2020-10-10 14:59:39 +02:00