[Mesa-dev] Statically linking libstdc++ and libgcc

Kai Wasserbäch kai at dev.carbon-project.org
Thu Mar 12 08:42:05 PDT 2015


Michel Dänzer wrote on 12.03.2015 08:15:
> On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
>> Hi - As you probably already know, there can only be one version of
>> libstdc++.so in your runtime link chain - This is usually not a problem,
>> but when things are linked against the Steam runtime (for example), they
>> can end up with two - one from the steam runtime, and one pulled in via
>> the mesa dri libs from the OS/distribution.
> 
> How can that happen? The problems I've seen related to this were usually
> because Steam overrides the system libstdc++ / libgcc with older
> versions, which breaks other system libraries.
> 
> Can somebody please tell Valve that doing that is not okay? And it's not
> necessary either. Each library can be compared to the system version
> individually and only overridden when necessary, e.g. by putting each
> library into its own directory and only adding the necessary directories
> to $LD_LIBRARY_PATH. E.g. VMware use this approach in their products.

This.

Though I'd actually like Valve to go even farther and at least start creating
dummy dependency packages for things they install. This way, they can ensure all
dependencies are met and they only have to ship closed-source stuff. Bonus
side-effect: only one copy of a library present, which gets updated by the
central package manager. If they use something like PackageKit they shouldn't
even have too much problems with the DEB/RPM split. Since you could generate
these dependencies automatically – SteamOS (aka Debian 7.x) is their base after
all, anything has to run there – that wouldn't constitute too much of a
maintenance burden either. (Obviously: true packages with a full build service
behind it, would be best, but I don't expect that to ever happen.) But I guess
everybody could be (mostly) happy with what Michel suggested.

And in addition to what has been said before: I wouldn't expect such a change to
take root in any (sane) distribution. So this change either turns into work for
the distributions (reverting the change) or the relevant configure option will
always be set to "disable".

Cheers,
Kai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150312/b47d1b9e/attachment.sig>


More information about the mesa-dev mailing list