[Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top
emil.l.velikov at gmail.com
Wed Oct 19 10:21:10 UTC 2016
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
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
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
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
I don't have any plans on tackling this.
More information about the mesa-dev