On 19/11/14 17:21, Jon TURNEY wrote:
On 19/11/2014 15:25, Jose Fonseca wrote:
No idea. But the impression I generally have is MinGW has come a long
way since then (3 years ago.)
I think there was at least one bug in mesa which prevented this from
working, see commit cedfd79b
Yes, you're prob
Am 19.11.2014 um 18:21 schrieb Jon TURNEY:
> On 19/11/2014 15:25, Jose Fonseca wrote:
>> No idea. But the impression I generally have is MinGW has come a long
>> way since then (3 years ago.)
>
> I think there was at least one bug in mesa which prevented this from
> working, see commit cedfd79b
A
On 19/11/2014 15:25, Jose Fonseca wrote:
No idea. But the impression I generally have is MinGW has come a long
way since then (3 years ago.)
I think there was at least one bug in mesa which prevented this from
working, see commit cedfd79b
___
mesa-d
No idea. But the impression I generally have is MinGW has come a long
way since then (3 years ago.)
I just noticed this while doing `git grep MINGW`. Because ideally we
should have very little things that depend on __MINGW32__ -- _WIN32 (ie.
platform), or __GNUC__ or _MSC_VER (ie compiler) ma
Reviewed-by: Roland Scheidegger
Do you know if that's due to MinGW changes or something else why it no
longer causes crashes?
Roland
Am 19.11.2014 um 13:10 schrieb jfons...@vmware.com:
> From: José Fonseca
>
> This reverts f4dd0991719ef3e2606920c5100b372181c60899.
>
> The src/gallium/tests/u
From: José Fonseca
This reverts f4dd0991719ef3e2606920c5100b372181c60899.
The src/gallium/tests/unit/translate_test.c gives the same results on
MinGW 64-bits as on Linux 64-bits. And since MinGW is often used for
development/testing due to its convenience, it's better not to have this
sort of d
