From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing) Date: Mon, 12 May 2014 17:46:40 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1576955031==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id B78EF6E932 for ; Mon, 12 May 2014 10:46:39 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1576955031== Content-Type: multipart/alternative; boundary="1399916799.df000.2482"; charset="us-ascii" --1399916799.df000.2482 Date: Mon, 12 May 2014 17:46:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D78242 --- Comment #4 from Daniel Scharrer --- > It's a steam bug, not a mesa one I disagree: this (na=C3=AFvely linking LLVM) is a change in mesa that break= s many binary software packages, not just Steam. While the steam-runtime will like= ly get a fix for this at some point, some older games may not be so lucky. Packaging libstdc++ and libgcc_s is relatively common with binary software packages targeting Linux - it is practically required in order to target a = wide range of distribution versions while not limiting yourself to an ancient compiler. Here is a small list of such packages that I happen to have insta= lled which bundle those libraries: $ find /{opt,usr/local/games}/ ~/Games/Trine/ -name 'libstdc++*' -o -name 'libgcc_s*' /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l= ibgcc_s.so /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l= ibstdc++.so /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l= ibstdc++.so.6 /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l= ibstdc++.so.6.0.10 /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l= ibgcc_s.so.1 /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libg= cc_s.so /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libs= tdc++.so /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libs= tdc++.so.6 /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libs= tdc++.so.6.0.10 /opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libg= cc_s.so.1 /opt/quake4/libstdc++.so.6 /opt/quake4/libgcc_s.so.1 /usr/local/games/sacred/lib/lib1/libstdc++.so.6 /usr/local/games/sacred/lib/lib1/libgcc_s.so.1 /usr/local/games/x2/lib/lib1/libstdc++.so.6 /usr/local/games/x2/lib/lib1/libgcc_s.so.1 /usr/local/games/postalx/postal2game/System/libstdc++.so.5 /usr/local/games/postalx/postal2game/System/libgcc_s.so.1 /usr/local/games/postalx/postal1game/libstdc++.so.5 /usr/local/games/postalx/postal1game/libgcc_s.so.1 /usr/local/games/aquaria/libstdc++.so.6 /usr/local/games/aquaria/libgcc_s.so.1 /usr/local/games/lugaru/libstdc++.so.6 /usr/local/games/lugaru/libgcc_s.so.1 /usr/local/games/survivor/lib32/libstdc++.so.6 /usr/local/games/survivor/lib32/libgcc_s.so.1 /usr/local/games/shadowgrounds/lib32/libstdc++.so.6 /usr/local/games/shadowgrounds/lib32/libgcc_s.so.1 /usr/local/games/coldwar/lib/libstdc++.so.6 /usr/local/games/coldwar/lib/libstdc++.so.6.0.8 /usr/local/games/postal2/System/libstdc++.so.5 /usr/local/games/postal2/System/libgcc_s.so.1 /usr/local/games/braid/libstdc++.so.6 /usr/local/games/braid/libgcc_s.so.1 /usr/local/games/testtool/lib/lib1/libstdc++.so.6 /usr/local/games/testtool/lib/lib1/libgcc_s.so.1 /usr/local/games/prey/libstdc++.so.5 /usr/local/games/prey/libgcc_s.so.1 /home/dscharrer/Games/Trine/lib32/libgcc_s.so.1 /home/dscharrer/Games/Trine/lib32/libstdc++.so.6 /home/dscharrer/Games/Trine/lib64/libstdc++.so.6 This has not been a problem in the past as system libraries (those you effectively have to link against to make full use of the hardware) have refrained from pulling in either of the GCC libraries. In fact, the only on= e I found doing this besides mesa is XvMC: $ for f in /lib/lib{dl,m,c,rt}.* /usr/lib/libasound* /usr/lib/libX* /usr/lib/libxcb* /usr/lib/mesa/* /usr/lib/opengl/{ati,xorg-x11}/lib/libGL* /usr/lib/libpulse* ; do ldd $f | grep -P '(libgcc|libstdc++)' | sed "s|^|$f= : |" ; done /usr/lib/libXvMCr600.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007fb39b72e000) /usr/lib/libXvMCr600.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007fb39ae6c000) /usr/lib/libXvMCr600.so.1: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f45d4a8f000) /usr/lib/libXvMCr600.so.1: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f45d41cd000) /usr/lib/libXvMCr600.so.1.0.0: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007fc235d72000) /usr/lib/libXvMCr600.so.1.0.0: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007fc2354b0000) /usr/lib/mesa/r200_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007ff45e80e000) /usr/lib/mesa/r200_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007ff45df4c000) /usr/lib/mesa/r300g_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f69359b7000) /usr/lib/mesa/r300g_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f69350f5000) /usr/lib/mesa/r600g_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f37f0e61000) /usr/lib/mesa/r600g_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f37f059f000) /usr/lib/mesa/radeon_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f5528868000) /usr/lib/mesa/radeon_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f5527fa6000) /usr/lib/mesa/radeonsi_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f4021a96000) /usr/lib/mesa/radeonsi_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f40211d4000) /usr/lib/mesa/swrast_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007f3bf7cc8000) /usr/lib/mesa/swrast_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007f3bf7406000) /usr/lib/mesa/swrastg_dri.so: libstdc++.so.6 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6 (0x00007fd0b4263000) /usr/lib/mesa/swrastg_dri.so: libgcc_s.so.1 =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1 (0x00007fd0b39a1000) This search includes fglrx's libGL by the way: The proprietary AMD (and I'm sure NVIDIA) drivers have long used C++ internally, but have taken care not= to pollute the global namespace with the C++ standard library or GCC helper library. I think this shows even more precedent that these libraries should= not be considered safe to use in base system libraries without additional precautions. What you are doing here is introducing additional problems where none exist= ed before. Please reconsider statically linking libLLVM and required C++/GCC l= ibs into *_dri.so or finding some other solution to not conflict with programs loading libGL. (An even stricter RTLD_LOCAL that completely namespaces libs would be nice to have here =E2=80=A6) For reference, here are a few more bugs caused by this: #30192, #30901, #38182, #38783, #43964, #66955 --=20 You are receiving this mail because: You are the assignee for the bug. --1399916799.df000.2482 Date: Mon, 12 May 2014 17:46:39 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Comment= # 4 on bug 78242<= /a> from Daniel Scharrer 
> It's a steam bug, not a mesa one

I disagree: this (na=C3=AFvely linking LLVM) is a change in mesa that break=
s many
binary software packages, not just Steam. While the steam-runtime will like=
ly
get a fix for this at some point, some older games may not be so lucky.

Packaging libstdc++ and libgcc_s is relatively common with binary software
packages targeting Linux - it is practically required in order to target a =
wide
range of distribution versions while not limiting yourself to an ancient
compiler. Here is a small list of such packages that I happen to have insta=
lled
which bundle those libraries:

$ find /{opt,usr/local/games}/ ~/Games/Trine/ -name 'libstdc++*' -o -name
'libgcc_s*'
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l=
ibgcc_s.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l=
ibstdc++.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l=
ibstdc++.so.6
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l=
ibstdc++.so.6.0.10
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/intel64/pinruntime/l=
ibgcc_s.so.1
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libg=
cc_s.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libs=
tdc++.so
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libs=
tdc++.so.6
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libs=
tdc++.so.6.0.10
/opt/intel/composerxe-2013.2.144/bin/sourcechecker/lib/ia32/pinruntime/libg=
cc_s.so.1
/opt/quake4/libstdc++.so.6
/opt/quake4/libgcc_s.so.1
/usr/local/games/sacred/lib/lib1/libstdc++.so.6
/usr/local/games/sacred/lib/lib1/libgcc_s.so.1
/usr/local/games/x2/lib/lib1/libstdc++.so.6
/usr/local/games/x2/lib/lib1/libgcc_s.so.1
/usr/local/games/postalx/postal2game/System/libstdc++.so.5
/usr/local/games/postalx/postal2game/System/libgcc_s.so.1
/usr/local/games/postalx/postal1game/libstdc++.so.5
/usr/local/games/postalx/postal1game/libgcc_s.so.1
/usr/local/games/aquaria/libstdc++.so.6
/usr/local/games/aquaria/libgcc_s.so.1
/usr/local/games/lugaru/libstdc++.so.6
/usr/local/games/lugaru/libgcc_s.so.1
/usr/local/games/survivor/lib32/libstdc++.so.6
/usr/local/games/survivor/lib32/libgcc_s.so.1
/usr/local/games/shadowgrounds/lib32/libstdc++.so.6
/usr/local/games/shadowgrounds/lib32/libgcc_s.so.1
/usr/local/games/coldwar/lib/libstdc++.so.6
/usr/local/games/coldwar/lib/libstdc++.so.6.0.8
/usr/local/games/postal2/System/libstdc++.so.5
/usr/local/games/postal2/System/libgcc_s.so.1
/usr/local/games/braid/libstdc++.so.6
/usr/local/games/braid/libgcc_s.so.1
/usr/local/games/testtool/lib/lib1/libstdc++.so.6
/usr/local/games/testtool/lib/lib1/libgcc_s.so.1
/usr/local/games/prey/libstdc++.so.5
/usr/local/games/prey/libgcc_s.so.1
/home/dscharrer/Games/Trine/lib32/libgcc_s.so.1
/home/dscharrer/Games/Trine/lib32/libstdc++.so.6
/home/dscharrer/Games/Trine/lib64/libstdc++.so.6

This has not been a problem in the past as system libraries (those you
effectively have to link against to make full use of the hardware) have
refrained from pulling in either of the GCC libraries. In fact, the only on=
e I
found doing this besides mesa is XvMC:

$ for f in /lib/lib{dl,m,c,rt}.* /usr/lib/libasound* /usr/lib/libX*
/usr/lib/libxcb* /usr/lib/mesa/* /usr/lib/opengl/{ati,xorg-x11}/lib/libGL*
/usr/lib/libpulse* ; do ldd $f | grep -P '(libgcc|libstdc++)' | sed "s=
|^|$f: |"
; done
/usr/lib/libXvMCr600.so:        libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007fb39b72e000)
/usr/lib/libXvMCr600.so:        libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007fb39ae6c000)
/usr/lib/libXvMCr600.so.1:      libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007f45d4a8f000)
/usr/lib/libXvMCr600.so.1:      libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007f45d41cd000)
/usr/lib/libXvMCr600.so.1.0.0:  libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007fc235d72000)
/usr/lib/libXvMCr600.so.1.0.0:  libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007fc2354b0000)
/usr/lib/mesa/r200_dri.so:      libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007ff45e80e000)
/usr/lib/mesa/r200_dri.so:      libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007ff45df4c000)
/usr/lib/mesa/r300g_dri.so:     libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007f69359b7000)
/usr/lib/mesa/r300g_dri.so:     libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007f69350f5000)
/usr/lib/mesa/r600g_dri.so:     libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007f37f0e61000)
/usr/lib/mesa/r600g_dri.so:     libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007f37f059f000)
/usr/lib/mesa/radeon_dri.so:    libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007f5528868000)
/usr/lib/mesa/radeon_dri.so:    libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007f5527fa6000)
/usr/lib/mesa/radeonsi_dri.so:  libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007f4021a96000)
/usr/lib/mesa/radeonsi_dri.so:  libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007f40211d4000)
/usr/lib/mesa/swrast_dri.so:    libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007f3bf7cc8000)
/usr/lib/mesa/swrast_dri.so:    libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007f3bf7406000)
/usr/lib/mesa/swrastg_dri.so:   libstdc++.so.6 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libstdc++.so.6
(0x00007fd0b4263000)
/usr/lib/mesa/swrastg_dri.so:   libgcc_s.so.1 =3D>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre9999/libgcc_s.so.1
(0x00007fd0b39a1000)

This search includes fglrx's libGL by the way: The proprietary AMD (and I'm
sure NVIDIA) drivers have long used C++ internally, but have taken care not=
 to
pollute the global namespace with the C++ standard library or GCC helper
library. I think this shows even more precedent that these libraries should=
 not
be considered safe to use in base system libraries without additional
precautions.

What you are doing here is introducing additional problems where none exist=
ed
before. Please reconsider statically linking libLLVM and required C++/GCC l=
ibs
into *_dri.so or finding some other solution to not conflict with programs
loading libGL. (An even stricter RTLD_LOCAL that completely namespaces libs
would be nice to have here =E2=80=A6)

For reference, here are a few more bugs caused by this:
 #30192, #30901, #38182, #38783, #43964, #66955

You are receiving this mail because: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1399916799.df000.2482-- --===============1576955031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1576955031==--