On 28 April 2015 at 11:16, Jose Fonseca <jfons...@vmware.com> wrote: > 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. > > It seems to me that there is no agreement atm :-(
> 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 > > Good catch. I would assume that as we mandate GCC 4.2 we should be save, although the configure check won't hurt either. > - 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 > > We already use version scripts for the gallium drivers (dri, vdpau...) due to static linking LLVM, which causes similar problem. > > > 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. > Great write-up Jose. Thank you very much. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
