Op 20-08-13 20:14, Matt Turner schreef:
> On Tue, Aug 20, 2013 at 8:54 AM, Maarten Lankhorst
> <maarten.lankho...@canonical.com> wrote:
>> 1. There is a new gallium based osmesa, which doesn't work correctly with 
>> wine. My testcase is running opengl32_test from wine/dlls/opengl32/tests.
>> I've pushed a few fixes, but gave up after I was still hitting a memcpy 
>> error in valgrind on those tests. There's no option to disable the new 
>> osmesa,
>> and by default it will build both and install both to the same place, 
>> overwriting itself..
> Oh, that's going to be obnoxious for distributions.
>
>> 2. Parallel builds from the same source directory fails because 
>> mesa/mapi/glapi/gen and performs writes to the source directory.
>> A simple automake patch seems to fix it.. (attached below)
> What do I have to do to reproduce this? I tried multiple out-of-source
> builds without the patch and it never failed.
The generated files are written to the source directory, which was fixed with 
the patch right below in my reply.

if you have multiple *parallel* builds running at the same time you may hit a 
bug where one is truncating the files in $(srcdir)/src/mapi/glapi/gen, and the 
other one just finished generating them, and is building in 
$(builddir)/src/mapi/glapi.

It's easy to trigger in debian with a package build, because the linux CFQ 
scheduler will cause the normal and swx11 build to happen almost 
simultaneously, which makes this race a lot more likely to hit.
The fix was simply generating the files in the builddir, which seems to work 
correctly now without any further changes because mesa uses autotools 
everywhere.

~Maarten
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to