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