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

[Jose Fonseca]

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 at 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=
>