[Mesa-stable] [Mesa-dev] nesa-10.4.4: gallivm/lp_bld_misc.cpp:503:38: error: no viable conversion from 'ShaderMemoryManager *' to 'std::unique_ptr<RTDyldMemoryManager>'

[Sedat Dilek]

On Fri, Mar 6, 2015 at 8:06 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 4 March 2015 at 18:07, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 04.03.2015 um 12:38 schrieb Jose Fonseca:
>>> On 04/03/15 02:00, Emil Velikov wrote:
>>>> On 27 February 2015 at 23:28, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>>>>> On Mon, Feb 9, 2015 at 6:30 PM, Emil Velikov
>>>>> <emil.l.velikov at gmail.com> wrote:
>>>>>> On 07/02/15 21:44, Sedat Dilek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was building mesa v10.4.4 with my llvm-toolchain v3.6.0rc2.
>>>>>>>
>>>>>>> My build breaks like this...
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> Please cherry-pick...
>>>>>>>
>>>>>>> commit ef7e0b39a24966526b102643523feac765771842
>>>>>>> "gallivm: Update for RTDyldMemoryManager becoming an unique_ptr."
>>>>>>>
>>>>>>> ..for mesa 10.4 Git branch.
>>>>>>>
>>>>>> Hi Sedat,
>>>>>>
>>>>>> Picking a fix in a stable branch against a non-final release sounds
>>>>>> like
>>>>>> a no-go in our books. As the official llvm 3.6 rolls out we'll pick
>>>>>> this
>>>>>> fix for the stable branches - until then I would recommend (a) applying
>>>>>> it locally or (b) using mesa from the 10.5 or master branch.
>>>>>>
>>>>>
>>>>> Just FYI...
>>>>>
>>>>> [LLVMdev] LLVM 3.6 Release (see [1]).
>>>>>
>>>>> Please pick this patch for-10.4, thanks.
>>>>>
>>>> As promised, mesa 10.4.6 will feature this.
>>>
>>> But is cross-porting this patch enough?
>>>
>>> As I said when this first issue was raised fixing the build with LLVM
>>> 3.6 is just half of the problem.  It must also _run_ correctly.  And
>>> building correctly doesn't necessarily means it will run correctly.
>>>
>>>
>>>
>>> That is, unless somebody actually ensures that all LLVM 3.6 related
>>> fixes have been crossported and that things run correctly, it is
>>> misleading to enable the build of Mesa 10.4.6 with LLVM 3.6.
>>>
>>> I don't know about radeon drivers, but at least from llvmpipe POV I
>>> simply don't have the time to do this (go through every LLVM 3.6 related
>>> patch, ensure they are all in 10.4.6, and test).
>>>
>>>
>>> I quickly went through the diffs between 10.4 branch, and found one such
>>> commit is missing:
>>>
>>>
>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=74f505fa73eda0c9b5b1984bebb44cedac8e8794
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=85467
>>>
>>> But there might be more, and I don't know if crossporting this is safe
>>> or not.
>>>
>>>
>>> Therefore my stance for is that building Mesa stable releases with LLVM
>>> releases after the Mesa release was branched is still unsupported.  If
>>> people want to do so, they will do at their own peril. And any incoming
>>> bugs will be "unsupported, use Mesa.
>>>
>>>
>>> If having a Mesa release capable of building LLVM 3.6 is so important, I
>>> think it might be easier/safer to just make a new release from a recent
>>> enough commit, than trying to backport it.
>>>
>>>
>>
>> This is quite right, the above commit is a must if you want to build
>> with llvm 3.6. I am quite sure crossport should be safe (it missed the
>> branch point of 10.4 just narrowly), and I don't think there's any other
>> patches missing, but no guarantees...
>> I think it is sort of unfortunate that the latest mesa release wouldn't
>> run with the latest llvm release, but the fact remains that without
>> testing this sounds all a bit risky...
>>
> Thanks for the input gents.
>
> So the input so far we've got is that no-one is testing llvm 3.6 with
> mesa 10.4. I love to give it a spin, yet Archlinux doesn't have llvm
> 3.6 . There is also the double-free bug mentioned in
> https://bugs.freedesktop.org/show_bug.cgi?id=89387
>
> All that said, Sedat I will revert the commit and release 10.4.6
> without it. On the positive side, mesa 10.5.0 is coming out later on
> today, which should work like a charm with llvm 3.6.
>

No, it breaks here as the "(compiler) visibility" fixes are still
missing when building with "--enable-glx-tls".

- Sedat -