Bug #11255
open
After GCC 7 switch dependencies on GCC runtime packages are incorrect
0%
Description
When a package depends on a library which can be found in RPATH and in standard path, pkgdepend generates require any dependency, like
depend fmri=pkg:/system/library/gcc-7-runtime@7.4.0-2018.0.0.0 fmri=pkg:/system/library/gcc-4-runtime@4.9.4-2018.0.0.6 type=require-any
for developer/build/make , which depends on libstdc++.so.6 and libgcc_s.so.1.
Now, when system already has gcc-4-runtime installed (and it will by default), which delivers runtime libraries in /usr/lib ,
when one installs developer/build/make, gcc-7-runtime is not installed and we likely have non-working make.
We've implemented the following workaround in oi-userland, when switched to GCC-6:
https://github.com/OpenIndiana/oi-userland/commit/90207d45219cd3f1aee0306db74122d7c9634aed
Likely, something similar should be implemented in illumos-gate (or we should fix pkgdepend and rely on it being fixed in build environment).
Updated by Alexander Pyhalov over 4 years ago
For OpenIndiana I've fixed it by illumos-gate transform in https://github.com/OpenIndiana/oi-userland/pull/5093.
Final suggested illumos-gate webrev is available here: http://buildzone.oi-build.r61.net/11255/.
Updated by Joshua M. Clulow over 3 years ago
What about, instead, if distributions delivered a correct and sufficiently recent GCC runtime into /usr/lib? This comes up with binaries built on other systems that are expected to run on many illumos distributions; e.g., the official Rust toolchain binaries. There isn't a way to nominate the correct RPATH for libgcc_s.so.1 in a way that is generally correct for all distributions -- but it doesn't seem like that should matter, as the library is generally backwards compatible, and distributions could (and, I feel, should?) just deliver the latest well-tested one into /usr/lib? The same should really apply to libssp.so.1.
Updated by Joshua M. Clulow over 3 years ago
I guess this may be less true of libstdc++, but I'm not sure on that one.
Updated by Alexander Pyhalov over 3 years ago
We've moved gcc runtime out of /usr/lib during 4.9 => 6 migration, as GCC 5 and 6 C++ runtimes were not compatible with 4.x.
Updated by Joshua M. Clulow over 3 years ago
That seems fair for the C++ one, I guess, though one might reasonably wonder why the incompatible one didn't end up with a new soname?
The C level ones aren't incompatible, though, right? (libgcc_s.so.1 and libssp.so.1)
Updated by Joshua M. Clulow over 3 years ago
I wonder if we should leave the libraries in version-specific directories, but use IPS mediators (which I am only just learning about!) to get the /usr/lib/libgcc_s.so* and /usr/lib/libssp.so* links in place.
Updated by Alexander Pyhalov over 3 years ago
We can do this if we are sure that our compilers completely ignore /usr/lib/libgcc_s.so*.
Otherwise there can be interesting effects, for example, when you build software on system with GCC 7-provided /usr/lib/libgcc_s.so*, and later transfer it to the system with GCC-4-provided /usr/lib/libgcc_s.so*.