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

[Jose Fonseca]

On 04/03/15 13:09, 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:
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_commit_-3Fid-3D74f505fa73eda0c9b5b1984bebb44cedac8e8794&d=AwIDaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=PMk0WwUp7tg8VPHe203a5V4y_-58iXhf8eswUxS2B9o&s=8MY01M7DtDFkyz21vhdPwVMJwvpe0NAIpJSv0wEGPDM&e=
>>
>>    https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D85467&d=AwIDaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=PMk0WwUp7tg8VPHe203a5V4y_-58iXhf8eswUxS2B9o&s=trSBFRNQPnckSosQ0RFj1vfFL3aFGiQQNLo8XNIxlqI&e=
>>
>> 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.
>
> 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.

That sounds good enough for me. Thanks.

>   - Tweak glGetString(GL_RENDERER) to return
> "Gallium 0.4 on llvmpipe. Unsupported LLVM version, LLVM 3.6"

It's fine not to do this (who knows what sort of regular expressions on 
GL_RENDERER are out there)

> 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.


74f505fa73eda0c9b5b1984bebb44cedac8e8794 cherry-picks cleanly on 10.4 
and there doesn't seem to be more missing patches AFAICT.

Jose