Emil Velikov <emil.l.veli...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
