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

[Emil Velikov]

On 19 April 2016 at 20:59, Tom Stellard <tom at stellard.net> wrote:
> On Tue, Apr 19, 2016 at 07:39:13PM +0100, 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 ?
>>
>
> The shared option is useful for development, because then you don't
> need to rebuild mesa every time you make an LLVM change, so I don't want
> to remove it.
>
> I don't really have a strong opinion of what should be default.  Static
> libraries have the disadvantage of requiring you to explicitly list the
> libraries you need, so if a library changes names or a new dependency is
> added, the build will break.
>
It does sound a bit annoying, but surely we can sort these out. There
are plenty people using/testing mesa+llvm trunk, so we're bound to get
reports and/or patches as things go south.

> Static libraries builds also take up a huge amount of disk/memory since
> each pipe driver and state tracker has their own copy of LLVM linked in.
>
Indeed, but we're better than before - we used to have multiple
separate driver (per state-tracker) which were (iirc) 70%+ identical.
Now we have only one ;-)

I have some work laying around to fold the radeon pipe-drivers into
one. There was also another to make things completely modular (i.e.
toggle between static and dynamic pipe-driver via a configure tweak).
Guess I need to revisit that one and finish it (convert Clover).

This way you'll get small state tracker libraries and just one
pipe-driver shared by all.

So in general any issues that we may have with static LLVM are not
impossible to resolve. Although based on your and Michel's request I
won't attempt removing shared LLVM support.

Just going to toggle it back to disabled, barring any objections of course.

Thanks
Emil