<div dir="ltr">If you recompile llvm and mesa each time, are there any downsides of using the shared libs?<div> </div><div>I think there were some issues with some programs / games that had clashing symbols but I'm not sure if that's still an issue</div></div> <div class="gmail_quote"><div dir="ltr">On Thu, 13 Oct 2016 at 11:15 Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13 October 2016 at 04:07, Michel Dänzer <<a href="mailto:michel@daenzer.net" class="gmail_msg" target="_blank">michel@daenzer.net</a>> wrote: > On 13/10/16 03:37 AM, Tobias Droste wrote: >> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov: >>>> >>>> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0 >>>> +LLVM_VERSION_REQUIRED_R600=3.6.0 >>>> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0 >>> >>> There's a small related gotcha: as-is at build time we get the >>> different codepaths thus, as people build against shared LLVM (hello >>> Archlinux, I'm looking at you) and update their LLVM without >>> rebuilding mesa (Arch I'm looking at you again) things go funny. > > What exactly happened there? LLVM upstream generates shared libraries > named libLLVM-<major>.<minor>.so*, so it shouldn't be possible for a > simple LLVM package update to break Mesa, unless Arch did something > really stupid. > The issue is not specific to Arch, but anyone who links against shared LLVM. Here is another take on it: At least swr and r600/radeonsi depend at _build_ time on the _patch_ version of LLVM. The latter of which is not part of the DSO name. Thus at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the "3.9.x" codepath even though you are be using "3.9.y" LLVM. If anything I'm calling it a LLVM bug, since shared/static library users should not need to know patch version, let alone have different codepaths based on it. Runtime ones might be ok, compile time definitely not. On our end, we could a) bump the requirement such that there's no compile time patch version check, b) suggest static linking or c) pretend the {mis,ab,}use isn't there ;-) > >>> Tl;Dr; We really want to enable static linking by default and prod >>> distros to use it. >> >> I'm all in favor of statically linking LLVM (that's the way I'm doing this on >> my pc). >> I think the only reason this is not done is because people (also here on the >> list) don't want any static linkg of external libraries because of size or >> whatever. >> So changing the default to static is easy, but I doubt it will make everyone >> happy ;-) > > Indeed, it'd probably make many distro packagers unhappy, because > they'll just have to re-enable shared linking, because packaging > policies generally strongly discourage if not outright forbid static > linking. > The toggle is there and is not going away, afaict. If people are going to get upset that the default does not meet their policy... just toggle and get on with other things ;-) Thanks Emil _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" class="gmail_msg" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div>