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

[Emil Velikov]

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++, while LLVM is shared.
How are exceptions going to propagate through, etc. is a bit magical, IMHO.

>> d3d1x is long gone, but seemingly clover is build these days.
>> Thus static linking LLVM is the way right approach in that case.
>>
>> Of course - everyone who knows the pros/cons of the toggle can adjust
>> it to their needs.
>>
>> I hope that with these in mind I could get your blessing (ack) on the patch?
>>
>
> I'm not a huge fan of having mesa work around bugs in other projects, but
> it would be fine with me if we had static linking by default for llvm <= 4.0
> and shared linking by default for llvm >= 5.0
>
Not a huge fan of hack either, I've been nagging you and others to
address some of the LLVM issues ;-)

Let's ignore the amount of version hacks we have and that adding
another one is not cool.

Changing the behaviour based on version is very bad since it's not
obvious/deterministic:
People/distros update LLVM and suddenly things behave differently.

Thanks
Emil