New Makemvk dependencey missing

[afewgoodman]

Comes back as:

"No package devtoolset-8 available."

I remember it might be included in epel-release.

# yum install epel-release

(base) [bchoi@localhost modprobe.d]$ yum list installed | grep devtoolset-8
devtoolset-8-binutils.x86_64 2.30-55.el7.1 @centos-sclo-rh
devtoolset-8-gcc.x86_64 8.3.1-3.1.el7 @centos-sclo-rh
devtoolset-8-gcc-c++.x86_64 8.3.1-3.1.el7 @centos-sclo-rh
devtoolset-8-libstdc++-devel.x86_64 8.3.1-3.1.el7 @centos-sclo-rh
devtoolset-8-runtime.x86_64 8.1-1.el7 @centos-sclo-rh
(base) [bchoi@localhost modprobe.d]$

BR.

[TrevorH]

No, devtoolset is a CentOS provided package but you have to install the right centos-release-whatever package to gain access to it.

I do not believe that it will fix this problem which is not with a CentOS provided package nor from a CentOS recommended repo. The epel-multimedia repo is entirely separate from the EPEL repo and its packages are provided by a third party. It's ONLY that third party that can fix this no matter how much talk there is in this forum and since that third party doesn't read this forum, it's pointless complaining about it here.

[Lazlow]

I had epel-release installed and active. Tracked stuff around a little more. IF you activate centos-extras it gives you a huge list of other repos including CentOS-SCLo-scl-rh.repo. Which has the devtoolset-8 stuff, it also has devlist-9(just to mention). I wonder if epel was hosting it before this other repo was set up?

By itself this did not solve the issue. Could you post the exact code for changing the path?

[chemal]

Devtoolsets do not not include a newer libstdc++.so.6. The new symbols that are not in the system's libstdc++.so.6 are in a static library. This is exactly to avoid producing binaries that would require a newer libstdc++.so.6.

[TrevorH]

And it is unlikely in the extreme that a newer libstdc++ will ever be introduced for CentOS 7. Please see the RHEL backporting link https://access.redhat.com/security/updates/backporting for details on how package versions are handled in RHEL (and thus CentOS).

In brief, most package versions are fixed in stone at the time of the initial release of the x.0 version and security fixes and enhancements are selectively backported to that code by Red Hat. It is very unusual for the package version to change during the 10 year lifespan of each major distro version as that is the whole point of RHEL/CentOS - to give stability and predictable upgrades for the entire lifetime of the distro. There are certain exceptions to those rules like firefox or rapidly moving things that don't have knock-on effects on other things but for things like libstdc++/glibc and other things that are extensively used within the distro, upgrades are almost never made.

[Lazlow]

I am very aware of the history of that stance. You and I are both aware that as the support life has increased so has that stance. An easy example would be the python situation. As the python 2 series has hit eol, RH had to add python 3. The sad part of that is RH knew that python 2 would hit eol long before RHEL7, yet they based everything off it. Python 3 was well along before RHEL7 was released so there was not any good reason to go with 2 rather than 3. I think even RH has changed it thoughts on this stance, just look at how RHEL8 is structured.

[chemal]

If you want to do something constructive, go to

https://www.makemkv.com/forum/viewforum.php?f=3

and suggest to build the closed-source binary with '-static-libstdc++'.

If you are successful, the next untested release from epel-multimedia will work again.

[Lazlow]

Their reply (and rightfully so) will be that the distro should be using or have available a current version of the library. Over the years I have been through this a number of times with a lot of different software. Currently I am in a similar issue with my Raspberry Pi and one of the graphics libraries(coin?) that Freecad (amongst others) requires.

[chemal]

Suit yourself.

[Lazlow]

The new version (.15?) is available as a snap.