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

[Emil Velikov]

On 13/03/15 22:10, Francisco Jerez wrote:
> Emil Velikov <emil.l.velikov at gmail.com> writes:
> 
>> 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.
>>
> 
> That belongs to your list of myths, see:
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html 
> 
Well spotted! As I've checked this (experimentally) some months ago, but
I wasn't 100% sure about it - thus the "seems" rather than "is".

Considering I cannot test atm (gcc 4.6 & gcc 4.7 fails to build), we'll
say that I was delusional and add it to the myths list :P

-Emil