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

[Michel Dänzer]

On 14/10/16 05:14 PM, Emil Velikov wrote:
> On 14 October 2016 at 01:45, Michel Dänzer <michel at daenzer.net> wrote:
>> On 13/10/16 07:14 PM, Emil Velikov 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.
>>
>> That should be fine, since 3.9.y is backwards compatible with 3.9.x.
>>
>> Debian doesn't automatically recompile Mesa in such cases either, and I
>> haven't seen any problems there because of that.
>>
>> So, what exactly was the problem?
>>
> Just grep through for LLVM_.*PATCH and you'll see it. Portable code
> should not check that at compile time.

This is getting a bit annoying... Please explicitly say what you think
is a problem, especially after being asked to do so multiple times.

I'm not sure about the swr instance, but the radeonsi instances are
fine. The worst that can happen is that the code uses the path for an
older patchlevel, even though the LLVM shared library used at runtime
actually has a newer patchlevel. I.e. the worst case is non-optimal
behaviour, not buggy behaviour.


>>>>>> 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 ;-)
>>
>> The question is if it makes sense for the default to be different from
>> what the majority of users end up using. It doesn't to me.
>>
> This might be better answered once you see what I mean above ;-)

I'm afraid you lost me here.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer