[Mesa-stable] [Mesa-dev] [PATCH 7/7] configure.ac: static link LLVM by default

[Emil Velikov]

On 12 October 2017 at 18:06, Michel Dänzer <michel at daenzer.net> wrote:
> On 12/10/17 06:49 PM, Emil Velikov wrote:
>> On 12 October 2017 at 17:33, Tom Stellard <tstellar at redhat.com> wrote:
>>> On 10/12/2017 07:14 AM, Emil Velikov wrote:
>>>> On 5 October 2017 at 18:11, Tom Stellard <tstellar at redhat.com> wrote:
>>>>> On 10/05/2017 08:40 AM, Emil Velikov wrote:
>>>>>> On 5 October 2017 at 16:16, Tom Stellard <tstellar at redhat.com> wrote:
>>>>>>> On 10/05/2017 06:33 AM, Michel Dänzer wrote:
>>>>>>>> On 05/10/17 12:19 PM, Emil Velikov wrote:
>>>>>>>>> From: Emil Velikov <emil.velikov at collabora.com>
>>>>>>>>>
>>>>>>>>> A while back Michel reported that LLVM has symbol versioning to avoid
>>>>>>>>> symbol collisions. Based on observations LLVM 5.0 is the first upstream
>>>>>>>>> version to actually has it.
>>>>>>>>
>>>>>>>> Not exactly. Adam Jackson originally added symbol versioning in LLVM 3.6
>>>>>>>> (in SVN r214418), but it was only effective when LLVM was built with
>>>>>>>> autotools. As of 5.0, it's effective with cmake as well.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Since symbol collisions do come up again and again (fortunately not so
>>>>>>>>> often) let's flip the switch back to static.
>>>>>>>>
>>>>>>>> It seems a bit weird to make this change now, that LLVM is solving the
>>>>>>>> issue for good. But I don't feel strongly about it.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I agree with this, symbol versioning should solve the issues with  symbol
>>>>>>> collisions, so why change this now?
>>>>>>>
>>>>>> LLVM with symbol versioning as not so widely used as I/we hope it was.
>>>>>> See the list in my other reply.
>>>>>>
>>>>>
>>>>> I looked at the list, but my preference is still that LLVM shared libraries
>>>>> should remain the default.  What is motivating the change to static by
>>>>> default?  Do the symbol collision problems affect most users?
>>>>>
>>>>> Static linking really just works around a bug/deficiency in older versions
>>>>> of LLVM and I think this is something distros should be handling.
>>>>>
>>>>> static linking has the added downside of build breakage when LLVM changes
>>>>> the component names for it's static libraries, which can be a pain.  Not
>>>>> to mention the increase in library size.
>>>>>
>>>>> As a compromise, if shared libraries are really causing a lot of issues,
>>>>> then maybe you could make static the default for for LLVM < 5.0, but I really
>>>>> prefer using shared libraries for all versions.
>>>>>
>>>> Looking the whole thing from another angle:
>>>>
>>>> I noticed that Fedora (RHEL?) has been using statlc libstdc++ for ~2 years.
>>>> In the packaging [1] there is this comment:
>>>>
>>>> # C++ note: we never say "catch" in the source.  we do say "typeid" once,
>>>> # in an assert, which is patched out above.  LLVM doesn't use RTTI or throw.
>>>> #
>>>> # We do say 'catch' in the clover and d3d1x state trackers, but we're not
>>>> # building those yet.
>>>>
>>>
>>> These comments refer to the use of the -frtti -fexceptions compiler flags.
>>> This doesn't really have anything to do the decision to statically or
>>> dynamically link LLVM.
>>>
>> Indeed - Michel pointed out the same thing. It's still very worrying ...
>>
>> Today both LLVM and Mesa are build with static libstdc++, [...]
>
> Neither LLVM nor Mesa upstream links libstdc++ statically by default.
>
I was still in the context of Fedora. Pardon, I should have made it clearer.

> BTW, with only Mesa linking LLVM statically on its own, without also
> linking libstdc++ statically in both LLVM and Mesa, it's still possible
> to run into issues with apps using their own, outdated shared libstdc++.
> IME that seems more common than issues due to multiple versions of
> shared LLVM ending up linked in the same process, which is the
> motivation for this change.
>
You're spot on here. I believe it's easier if one looks at the two as
separate issues.
Although yes, they are related.

>
>> Changing the behaviour based on version is very bad since it's not
>> obvious/deterministic:
>> People/distros update LLVM and suddenly things behave differently.
>
> It seems like distros are consciously linking LLVM dynamically or
> statically already, in which case none of this really affects them
> either way, but rather mostly upstream users of Mesa.
>
Precisely - the have the power to opt for either.

Thanks
Emil