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

Jose Fonseca jfonseca at vmware.com
Tue Apr 28 03:16:52 PDT 2015


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:


- 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:


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

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.


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=

More information about the mesa-dev mailing list