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

[Francisco Jerez]

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 

>
>
> 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
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150314/3a971614/attachment.sig>