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

[Emil Velikov]

Hi all,

Allow me to sum all that is said here, plus elaborate on some of the
myths and alternative solutions proposed.

Considering that this is a never ending and somewhat emotional topic, I
would kindly ask people to read this while in their happy place.


Myths
-----

 * "The LLVM-enabled variants of Mesa are the only implementations where
this is an issue"

Up-to recently all mesa drivers (not limited to LLVM) were using
__builtin_clrsb if supported. IIRC that symbol was introduced with GCC
4.7 and was also causing problems until the Steam runtime was updated.


 * "... they use a subset of C++ that prevents them from needing to link
with libstc++.  Use of LLVM prevents much of Mesa from using that option."

Based on reading the documentation and a quick test I did some ~3months
ago, using C++'s "new" leads to dependency of the C++ runtime.



The problem
-----------
 * Binary program X, ships it's own version of libgcc_s/libstdc++/foo.
This problem is not new, afaict it existed for over 10 years, and there
was never a single/simple/robust solution.


The solutions
-------------
 * Allow people to static link against libgcc/libstdc++.

Imho this should be option, disabled by default provided at configure
time. This way builders/distributions can op-in if they choose to do so.


 * Always use the libraries provided by the distribution.
 * Use PackageKit-like solution to check/manage dependencies.

In a open-source only environment this might work out but not for a
binary only program/library. The people behind the latter have limited
resources, thus it's virtually impossible to test it every distribution
out there for each update of the said dependency. Some libraries have
compatibility policies, some don't. Also distributions occasionally
patch the library, which might cause additional issues.


 * Use bundled library if newer (check the SONAME).

For libgcc_s at least, the library does not seems to be forward compatible.



All in all the way I see things are:

Valve has put their head in the bag, by providing and assuring that the
runtime environment does not break backwards compatibility. It's not a
pretty solution from a driver/system developer point of view, but as
said earlier "that cat is out of the bag". Although as a game developer,
this is a ideal solution as it gives them a certain level of guarantee,
and allows them to prioritise on making content.


So imho our best bet is to go with option 1 (allow people to static
link), but keep this option disabled by default, as we do with llvm.


My humble requests towards Vivek are:
 - Can we make this a configure option ?
 - Please drop patch #2 and the llvm one. If there is a problem with
static llvm help us address it ? There is a wall of reasons behind this
request but I'd spare them for today.

Fwiw just tried llvm 3.5.1 with all three mesa branches and things
compile like a charm. Afaict Kai has been doing this for quite some
time, even sent out patches for keep things working.


As a queue, I will share with you an old Bulgarian quote, which I
believe has it's version in almost any culture - A wise man knows when
to step back.


Have a lovely weekend all !


-Emil