On 12 October 2017 at 17:33, Tom Stellard <tstel...@redhat.com> wrote: > On 10/12/2017 07:14 AM, Emil Velikov wrote: >> On 5 October 2017 at 18:11, Tom Stellard <tstel...@redhat.com> wrote: >>> On 10/05/2017 08:40 AM, Emil Velikov wrote: >>>> On 5 October 2017 at 16:16, Tom Stellard <tstel...@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.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
