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

[Emil Velikov]

On 28 April 2015 at 11:16, Jose Fonseca <jfonseca at 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