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

[Emil Velikov]

On 19 October 2016 at 08:58, Michel Dänzer <michel at daenzer.net> wrote:
> On 18/10/16 11:39 PM, Emil Velikov wrote:
>> On 17 October 2016 at 08:56, Michel Dänzer <michel at daenzer.net> wrote:
>>> On 14/10/16 07:02 PM, Emil Velikov wrote:
>>>
>>>> * src/gallium/drivers/radeon/r600_pipe_common.c
>>>> No actual bug, yet misleading.
>>>
>>> If you want to call it that... I'd say this can be useful for detecting
>>> the problems you're thinking of. :)
>>>
>> On the contrary, for example:
>> Building against shared llvm 3.6.0, later one updates to 3.6.2.
>>
>> Mesa is not rebuild, thus the above message says "3.6.0" and they
>> don't get any tessellation.
>> Then they check with their package/install - Why is Mesa showing
>> 3.6.0, I have 3.6.2 installed. Should I reinstall LLVM, are there any
>> parts of 3.6.0 still around ?"
>
> My point is that all the information is there; even if not everybody can
> make sense of it, *somebody* can and explain to others what needs to be
> done.
>
True. One could add "build against" so that it reads "build against
LLVM XXX" or alike and we cut out the middle man ;-)

>> This in itself is because people don't expect that one should rebuild
>> package X when one its dependencies gets a patch version change.
>
> The same thing applies with static linking, though. Except then one
> doesn't get the benefit of any other additional fixes in the newer LLVM
> either without rebuilding Mesa.
>
>From my humble experience maintainers know that when using static
linking they need to rebuild the package alongside the static
dependency/ies.
Some distros, such as Debian, even have a flag which helps maintainers
which dependencies are static linked.

Anyway let's drop the nitpicking (myself including) and devote that
time to beating llvm/mesa into shape ?

>
>>>> Downgrade - TBD, depending on the (fixed) LLVM bugs.
>>>
>>> Building against one version of LLVM and then downgrading the shared
>>> library to an older version is indeed the only case we're currently not
>>> handling gracefully. It should be rather rare though.
>
> [...]
>
>>>> That or just bump the requirement ?
>>>
>>> That wouldn't protect against the shared library being downgraded to an
>>> older version.
>>>
>> Almost. AFAICT Mesa has (had for a long time) the implicit agreement
>> that the build-time requirements are identical to the run-time ones.
>>
>> If people use a lower [runtime] versions, things will explode in many
>> places. This is not specific/isolated to LLVM.
>
> Right, but this principle generally applies to the effective version of
> a shared library compiled against instead of its minimum required
> version.
Afaict this is only case for LLVM (in the swr and radeon drivers
alone) and wayland (which I seems to have forgotten to tackle).

Namely: mesa [aims to] provide you with consistent experience as you
build against foo vX and run against foo vY, even if Y < X.
As long as both X and Y cover the minimum requirement in configure.ac.

> I'm not sure raising the minimum required version would provide
> enough benefit to offset artificially preventing users with older
> versions from building Mesa. Have you seen any actual reports of users
> running into trouble because of this? I don't remember seeing any.
>
We already do so with libdrm [+ friends], xcb, xcb glx and xvmc. IIRC
we used to do that with vdpau and a few others a while back.

On the reports side - I won't bother remembering such ones, partially
because I would close them on the spot ;-)

If you want to untangle things and make it secure for people to use
v.N-1 at runtime even though the build requirement is vN, please go
ahead.
I don't have any plans on tackling this.

Thanks
Emil