0

I am attempting to install an RPM in my VM, and I am getting the following messages during yum install.

file /usr/lib64/libstdc++.so.6 from install of myPackage.x86_64 conflicts with file from package libstdc++-4.8.5-16.el7_4.2.x86_64
file /usr/lib64/libz.so.1 from install of myPackage.x86_64 conflicts with file from package zlib-1.2.7-17.el7.x86_64
file /usr/lib64/libgcc_s.so.1 from install of myPackage.x86_64 conflicts with file from package libgcc-4.8.5-16.el7_4.2.x86_64
file /usr/lib64/libgomp.so.1 from install of myPackage.x86_64 conflicts with file from package libgomp-4.8.5-16.el7_4.2.x86_64
file /usr/lib64/libgomp.so.1.0.0 from install of myPackage.x86_64 conflicts with file from package libgomp-4.8.5-16.el7_4.2.x86_64

I am running in Centos7, and I am pretty sure that the libstdc++-4.8.5-16 is coming in since I installed gdb (I am installing a set of pre-packaged RPMS) from the Centos repos.

Is there a way to resolve these conflicts? Is there a way to tell gdb, for example, to use the more up-to-date libstdc++ library?

Niall
  • 30,036
  • 10
  • 99
  • 142
Mark
  • 2,058
  • 2
  • 35
  • 64
  • What RPM are you attempting to install? Anyway this really seems like a question for Server Fault or Super User, as it's just about managing software packages on your computer. – Lightness Races in Orbit Mar 13 '18 at 22:17

1 Answers1

4

Whatever mystery package you are attempting to install is badly behaved. It is trying to install some shared library files that, by rights, are "owned" by the libstdc++ package on CentOS 7. Yum is correctly rejecting the mystery package due to this misbehaviour.

You should talk to the package author and inform them that their package does not meet quality guidelines. If they are writing software that definitely, absolutely needs a newer version of libstdc++ than is officially distributed in this environment, then they could:

  • Use devtoolset, or
  • statically link the runtime, or
  • package the newer shared library but install it somewhere isolated, at a location that will only be used by the mystery software. It must not take over from the platform's own packages unless you want it to cause weird runtime behaviours as every other C++ application on the system suddenly links with some mystery newer version of the GCC runtime library.

If different shared library versions are not required, then instead the author should:

  • build against the officially distributed libraries in the first place, and
  • denote prerequisites in their RPM's .spec file... to, e.g. libstdc++ & libgomp.
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055