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. > 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 -Tom > Thanks > Emil > > [1] http://pkgs.fedoraproject.org/cgit/rpms/mesa.git/tree/mesa.spec#n387 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
