Hi,
I don't know if in the end of this thread there was an agreement that
Valve should only use bundled libstdc++ if it's newer than the system's
libstdc++, or just no agreement at all.
But just for future reference (or in case any distro decides to apply
the patches themselves), I'd like to point out there a couple of
technical issues with the proposed patch.
I actually modified apitrace's LD_PRELOAD wrappers precisely as Vivek
proposed (so apitrace can safely trace any application, without fear of
symbol collision, no matter what), but ran against two problems:
- For a long time static libstdcxx wasn't built with -fPIC ( see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 ) so I actually had
to add a configure-time check to see whether it works or not:
https://github.com/apitrace/apitrace/commit/09531388e2aea19018ef03487d37a12547eb9325
- libstdc++.a's symbols are not hidden (they have default visibility),
and while `-Wl,--exclude-libs,libstdc++.a` prevents normal libstdc++.a's
symbols from being exported, it does not work for weak symbols. Ie,
weak symbols from libstdc++.a's are still exported, and can clash with
the weak symbols from the dynamically linked libstdc++.so.
(Ironically I spotted this issue while tracing with Mesa's drivers.)
So in the end I had to actually use LD version scripts:
https://github.com/apitrace/apitrace/commit/946652f4fc103854d4f643551331eb72e8fb0345
IMHO I think that the solution that makes more sense for Valve is to
manipulate LD_LIBRARY_PATH so that libstdc++ is only picked when
necessary (newer than systems'), as Michel suggested. It's the only way
to guarantee maximum compatibility.
Mesa could provide the option to statically link libstdc++, as defense
against thirdparty vendors that invariable dynamically link their own.
But it seems unrealistic for a thirdparty app vendor to assume it's safe
to always use a bundled libstdc++. It's a matter of time until a system
component relies on libstdc++.so. If it's not Mesa driver, it could be
anything else. Here's for example all system shared objects are are
loaded by CSGO on my home laptop:
$ cat /proc/`pidof csgo_linux`/maps | grep -o '\s/\(usr/\)\?lib\S\+' |
sort -u
/lib/i386-linux-gnu/i686/cmov/libc-2.19.so
/lib/i386-linux-gnu/i686/cmov/libdl-2.19.so
/lib/i386-linux-gnu/i686/cmov/libm-2.19.so
/lib/i386-linux-gnu/i686/cmov/libnsl-2.19.so
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.19.so
/lib/i386-linux-gnu/i686/cmov/libpthread-2.19.so
/lib/i386-linux-gnu/i686/cmov/libresolv-2.19.so
/lib/i386-linux-gnu/i686/cmov/librt-2.19.so
/lib/i386-linux-gnu/ld-2.19.so
/lib/i386-linux-gnu/libudev.so.1.5.0
/usr/lib/i386-linux-gnu/dri/i965_dri.so
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
/usr/lib/i386-linux-gnu/gconv/UTF-32.so
/usr/lib/i386-linux-gnu/libdrm_intel.so.1.0.0
/usr/lib/i386-linux-gnu/libdrm_nouveau.so.2.0.0
/usr/lib/i386-linux-gnu/libdrm_radeon.so.1.0.1
/usr/lib/i386-linux-gnu/libdrm.so.2.4.0
/usr/lib/i386-linux-gnu/libglapi.so.0.0.0
/usr/lib/i386-linux-gnu/libGL.so.1.2.0
/usr/lib/i386-linux-gnu/libpciaccess.so.0.11.1
/usr/lib/i386-linux-gnu/libxshmfence.so.1.0.0
/usr/lib/locale/locale-archive
Who can say for sure that one of these won't get one day rewriten on
C++, or introduces a new dependency on a module written in C++??
In short, although I personally have no objection of providing the
option to build Mesa with static libstdc++, I think it's unsustainable
for Valve to keep making this assumption.
Jose
On 12/03/15 01:36, Vivek Dasmohapatra wrote:
Here's a version of the mesa build patches rolled into one patch,
and driven by a configure argument --enable-static-libstdc++
which defaults to being off.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=yTS0Ql-3ju2hxd1F6b0bbyzh4c5RMUJ6fQ5VxEirHew&s=VUxQjS5Gk3rA1xb9ghLKF-x2lRdNstZJ0yEdwEiZPng&e=
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
