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

[Michel Dänzer]

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.

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.


> 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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer