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

[Tom Stellard]

On 03/04/2015 08:09 AM, Emil Velikov wrote:
> On 04/03/15 11:38, Jose Fonseca wrote:
>> 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.
>>
> Suspecting that the AMD guys (Tom ?) can comment on their end, but I'm
> hoping for some middle ground/compromise.
>

The 10.5 release needs to work with LLVM 3.6, and I have automated 
testing for this on radeonsi, so I should be able to catch most issues.

In theory, radeonsi in the 10.4 release will also work with LLVM 3.6,
but I'm not testing this use case, so it's not really that important to me.

-Tom


> Based on your suggestions how about if we:
>   - Add a big note in the release announcement (+ notes)
> "Mesa has been tested to build against llvm 3.6 but there is no official
> support".
>   - Add a warning message at configure time, similar to above.
>   - Tweak glGetString(GL_RENDERER) to return
> "Gallium 0.4 on llvmpipe. Unsupported LLVM version, LLVM 3.6"
>
> How does this sound ? If Tom is also leaning towards no llvm 3.6 support
> for 10.4 I'll revert the patch before making the release. Otherwise I
> can get the above two for Friday.
>
> Thanks
> Emil
>