Bug #11255

After GCC 7 switch dependencies on GCC runtime packages are incorrect

Added by Alexander Pyhalov over 1 year ago. Updated 6 months ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


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 and

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:

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 1 year ago

For OpenIndiana I've fixed it by illumos-gate transform in

Final suggested illumos-gate webrev is available here:


Updated by Joshua M. Clulow 6 months 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 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


Updated by Joshua M. Clulow 6 months ago

I guess this may be less true of libstdc++, but I'm not sure on that one.


Updated by Alexander Pyhalov 6 months 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 6 months 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? ( and


Updated by Alexander Pyhalov 6 months ago

Seems so.


Updated by Joshua M. Clulow 6 months 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/* and /usr/lib/* links in place.


Updated by Alexander Pyhalov 6 months ago

We can do this if we are sure that our compilers completely ignore /usr/lib/*.
Otherwise there can be interesting effects, for example, when you build software on system with GCC 7-provided /usr/lib/*, and later transfer it to the system with GCC-4-provided /usr/lib/*.

Also available in: Atom PDF