I did upgrade my system recently (which I deeply regret). My currently selected GCC profile is x86_64-pc-linux-gnu-6.3.0, and I have already ran `revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc` to no effect. I have rebuild primus also, also to no effect.

primsrun glxspheres works fine, as well as primusrun glxspheres64

Does anyone have any clue of which package I should rebuild to get primus working again? Or there is something wrong with the paths?

The missing symbol is the post-update name. I suspect that the program is somehow finding a pre-upgrade libstdc++. Steam is notorious for bundling libraries they should not, so this would explain why your basic GLX test works correctly, but your Steam game fails. What is the output of (cd /path/to/steam/files && find . -name libstdc++\* -ls)? I used a cd to anonymize the path. Otherwise you could have given the path instead of ..

In some cases, users have reported success by denying Steam access to the bundled copy and forcing it to use the system copy instead. Keep a backup of the file if you try this, since it is a context-dependent solution and we currently do not know if that will help.

The missing symbol is the post-update name. I suspect that the program is somehow finding a pre-upgrade libstdc++. Steam is notorious for bundling libraries they should not, so this would explain why your basic GLX test works correctly, but your Steam game fails. What is the output of (cd /path/to/steam/files && find . -name libstdc++\* -ls)? I used a cd to anonymize the path. Otherwise you could have given the path instead of ..

In some cases, users have reported success by denying Steam access to the bundled copy and forcing it to use the system copy instead. Keep a backup of the file if you try this, since it is a context-dependent solution and we currently do not know if that will help.

Indeed you're right; there are a bunch of versions of libstdc++ in $HOME/.local/share/Steam. I didn't think that they would be favoured, however, 'cause of the STEAM_RUNTIME_PREFER_HOST_LIBRARIES=1 environment variable. Steam's libraries seem to be compiled with gcc-4.6, so anything with gcc-5 or later will cause troubles.

Which is troublesome in itself. It does have libGLES, libGLEW and libGLU, but it is trying to use libGL from the system. Mixing system and Steam's libs do not sound like a good idea in any case.

Is there any beautiful mechanism in Gentoo which will allow me to keep one version of libGL compiled specially with gcc-4.6 to be used by Steam, or is that asking too much? _________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)

I am not aware of one. Perhaps you could get the Steam developers (not the Gentoo maintainers for Steam, but Valve's employees) to fix their workflow. They should have updated to gcc-5 by now. They also shouldn't be bundling so many libraries, but convincing them of their error there is unlikely.

I am not aware of one. Perhaps you could get the Steam developers (not the Gentoo maintainers for Steam, but Valve's employees) to fix their workflow. They should have updated to gcc-5 by now. They also shouldn't be bundling so many libraries, but convincing them of their error there is unlikely.

I cannot argue with them in that aspect. The games will come precompiled, there is no way around that. What would happen if the game compiled with gcc4 is dynamically linked to my system library compiled with gcc6? Some games ship their own versions of some of libraries in Steam Runtime._________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)

Mixing gcc4 with gcc6 should be fine if they stick to supported interfaces. There will be problems, like the ones you saw here, if they rely on symbols which changed ABI. The only solution is for someone to rebuild the code with the new ABI. We can't do that for them since they refuse to release the source, so the problem falls to them. In most cases, a straight rebuild is all that is required. No code changes, so this should be very easy for them to do.

Mixing gcc4 with gcc6 should be fine if they stick to supported interfaces. There will be problems, like the ones you saw here, if they rely on symbols which changed ABI. The only solution is for someone to rebuild the code with the new ABI. We can't do that for them since they refuse to release the source, so the problem falls to them. In most cases, a straight rebuild is all that is required. No code changes, so this should be very easy for them to do.

I think it is "asking too much" to tell them that. Most developers are completely unaware of those intricacies and for a good reason - to each their speciality.

I'm just adding here the information that this is a relatively known complaint about Steam. People have been asking when they will release a Steam Runtime environment compiled with GCC-5 and GCC-6, but the the developers would all have to recompile their games with the new libstdc++. The only reasonable solution, as it seems, is to favour static linking for libstdc++ rather than dynamic._________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)

Steam already bundles plenty of libraries. It shouldn't be a big issue for them to bundle multiple versions of libstdc++ and select which to use based on whether the game has been updated.

I'd definitely like to see more Steam games statically link libstdc++ though. As I read the libstdc++ license, static linking it would obligate them to license the main executable under the GNU General Public License, at which point they'd have to release the source to customers, and then we could rebuild it with the proper options.

Steam already bundles plenty of libraries. It shouldn't be a big issue for them to bundle multiple versions of libstdc++ and select which to use based on whether the game has been updated.

I'd definitely like to see more Steam games statically link libstdc++ though. As I read the libstdc++ license, static linking it would obligate them to license the main executable under the GNU General Public License, at which point they'd have to release the source to customers, and then we could rebuild it with the proper options.

Yeah, right. We might as well wait for the end of world hunger while we're at that

If that's the case, I don't see how gaming in Linux would have any future. We cannot expect developers to keep reworking their 10 years old games to conform the new interfaces of newer libraries. Also expecting Steam to keep track of all sort of combinations of old and new libraries and providing them in an extended period of time is quite unrealistic.

I am not aware of anything more than a simple rebuild required for this upgrade. If the vendor has kept its build system in order, that should be trivial for them to do. This differs a bit from some open source libraries that are infamous for frequently changing their API, which would impose an actual burden on the vendor.

As far as I know, the gcc developers have never promised that you could do what Steam does and expect it to keep working long term. Steam ought either to bundle all the libraries it needs, or bundle nothing and have a policy for rebuilding when libraries update. Bundling some things and not others is an invitation for trouble.

I am also unaware of any proprietary vendors that have publicly requested any assistance in this area. Since the vendors never asked for help, and gcc never promised it, it seems to me that the fault lies squarely on the vendors who failed to prepare for this, either by asking gcc to handle it differently, by refraining from use of libstdc++, or by preparing to rebuild as needed. Note also that gcc-5 was released April 2015. Vendors have now had more than 2 years to do a fairly simple upgrade. If they can't even do that, they're probably not supporting the game at all, even for serious bugs or security issues.