On 12 October 2017 at 18:06, Michel Dänzer <mic...@daenzer.net> wrote: > On 12/10/17 06:49 PM, Emil Velikov wrote: >> 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++, [...] > > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
