[Mesa-dev] [PATCH] configure.ac: fix the --disable-llvm-shared-libs build

[Jose Fonseca]

On 19/04/16 19:39, Emil Velikov wrote:
> Hi Chuck,
>
> Thanks for chipping in.
>
> On 19 April 2016 at 15:47, Chuck Atkins <chuck.atkins at kitware.com> wrote:
>> This still doesn't quite give what you want.  One can also have an llvm with
>> component shared libs.  So there's three different options for llvm library
>> configurations: a single shared lib, component shared libs, or component
>> static libs.
>  From the three - only single shared lib and component static libs are supported.
>
> Personally I'm leaning that we ought to go with the latter only... Esp
> considering the problems that people tend to have with mesa + steam,
> every so often.
>
> IIRC all the issues that we had with static llvm have been resolved.
> Plus we have great people like Kai who promptly send patches when
> things break (which hasn't happen in a long time)
>
> Tom, what is your view on the topic - are you ok with us switching
> back to static one and/or nuking the shared one ? Iirc Jose was clear
> that in his view one should just static link LLVM. I believe that's
> still the case, right Jose ?

Yes, I think that distros should statically link LLVM.  Otherwise Mesa's 
LLVM can clash with other projects LLVM, which can and often do require 
a different LLVM version.  And there's *lots* of projects out there that 
use LLVM and OpenGL, particularly languages w/ JIT compilation.


That said, I have no objection to allow shared LLVM as an option, 
particularly if improves developer productivity.   I'd still recommend 
the default would be static and printing a warning when using shared 
LLVM to warn about the pitfalls.


I always statically link LLVM on my case, but unlike Tom I seldom 
develop on LLVM itself, and I do strip debugging info from LLVM static 
libraries to avoid huge binaries and slow link time.


Anyway, this is just my 2c.  As long as the option to link LLVM 
statically doesn't go away, I'm happy.


Jose