[Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

Mike Lothian mike at fireburn.co.uk
Thu Oct 13 14:16:04 UTC 2016


If you recompile llvm and mesa each time, are there any downsides of using
the shared libs?

I think there were some issues with some programs / games that had clashing
symbols but I'm not sure if that's still an issue

On Thu, 13 Oct 2016 at 11:15 Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 13 October 2016 at 04:07, Michel Dänzer <michel at daenzer.net> wrote:
> > On 13/10/16 03:37 AM, Tobias Droste wrote:
> >> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
> >>>>
> >>>> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
> >>>> +LLVM_VERSION_REQUIRED_R600=3.6.0
> >>>> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
> >>>
> >>> There's a small related gotcha: as-is at build time we get the
> >>> different codepaths thus, as people build against shared LLVM (hello
> >>> Archlinux, I'm looking at you) and update their LLVM without
> >>> rebuilding mesa (Arch I'm looking at you again) things go funny.
> >
> > What exactly happened there? LLVM upstream generates shared libraries
> > named libLLVM-<major>.<minor>.so*, so it shouldn't be possible for a
> > simple LLVM package update to break Mesa, unless Arch did something
> > really stupid.
> >
> The issue is not specific to Arch, but anyone who links against shared
> LLVM.
>
> Here is another take on it:
> At least swr and r600/radeonsi depend at _build_ time on the _patch_
> version of LLVM. The latter of which is not part of the DSO name. Thus
> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
> "3.9.x" codepath even though you are be using "3.9.y" LLVM. If
> anything I'm calling it a LLVM bug, since shared/static library users
> should not need to know patch version, let alone have different
> codepaths based on it. Runtime ones might be ok, compile time
> definitely not.
>
> On our end, we could a) bump the requirement such that there's no
> compile time patch version check, b) suggest static linking or c)
> pretend the {mis,ab,}use isn't there ;-)
>
> >
> >>> Tl;Dr; We really want to enable static linking by default and prod
> >>> distros to use it.
> >>
> >> I'm all in favor of statically linking LLVM (that's the way I'm doing
> this on
> >> my pc).
> >> I think the only reason this is not done is because people (also here
> on the
> >> list) don't want any static linkg of external libraries because of size
> or
> >> whatever.
> >> So changing the default to static is easy, but I doubt it will make
> everyone
> >> happy ;-)
> >
> > Indeed, it'd probably make many distro packagers unhappy, because
> > they'll just have to re-enable shared linking, because packaging
> > policies generally strongly discourage if not outright forbid static
> > linking.
> >
> The toggle is there and is not going away, afaict. If people are going
> to get upset that the default does not meet their policy... just
> toggle and get on with other things ;-)
>
> Thanks
> Emil
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161013/26a7c618/attachment.html>


More information about the mesa-dev mailing list