Project

General

Profile

Bug #11255

After GCC 7 switch dependencies on GCC runtime packages are incorrect

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

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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).

History

#1

Updated by Alexander Pyhalov over 1 year 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/.

#2

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

#3

Updated by Joshua M. Clulow 2 months ago

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

#4

Updated by Alexander Pyhalov 2 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.

#5

Updated by Joshua M. Clulow 2 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? (libgcc_s.so.1 and libssp.so.1)

#6

Updated by Alexander Pyhalov 2 months ago

Seems so.

#7

Updated by Joshua M. Clulow 2 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/libgcc_s.so* and /usr/lib/libssp.so* links in place.

#8

Updated by Alexander Pyhalov 2 months 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*.

Also available in: Atom PDF