On 19 October 2016 at 08:58, Michel Dänzer <mic...@daenzer.net> wrote: > On 18/10/16 11:39 PM, Emil Velikov wrote: >> On 17 October 2016 at 08:56, Michel Dänzer <mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
