On 23 May 2016 at 22:19, Rob Clark <robdcl...@gmail.com> wrote: > On Mon, May 23, 2016 at 5:16 PM, Mark Janes <mark.a.ja...@intel.com> wrote: >> I run a buildtest in our CI to help Intel engineers avoid breaking the >> builds for other Mesa targets. >> >> With this commit, it produces: >> >> make[2]: Entering directory '/home/majanes/src/mesa/src/gbm' >> CCLD libgbm.la >> backends/dri/.libs/gbm_dri.o: In function `mtx_init': >> /home/majanes/src/mesa/src/gbm/../../include/c11/threads_posix.h:189: >> undefined reference to `pthread_mutexattr_init' >> /home/majanes/src/mesa/src/gbm/../../include/c11/threads_posix.h:190: >> undefined reference to `pthread_mutexattr_settype' >> /home/majanes/src/mesa/src/gbm/../../include/c11/threads_posix.h:192: >> undefined reference to `pthread_mutexattr_destroy' >> collect2: error: ld returned 1 exit status > > apparently this happens with -O0 (since otherwise the compiler > dead-code-eliminates the references?). I'm using the attached hack > patch for now, but hopefully this is solved properly somehow ASAP.. > [Repeating for those who were not in #dri-devel earlier today]
Sadly forcing all the -f flags from -O1 does not eliminate the code and still flags the above error. I.e. one cannot toggle the optimisation locally forcing GCC to optimise the hunk. Another solution would be to add a few weak declarations for the said functions in the c11 headers (props to Ilia for the idea), alternatively we can force pthreads for gbm (not that great of idea imho) or add a #define ALLOW_MUTEXATTR workaround for the single recursive mutex in mesa. Personally I'm leaning towards the first one, but I'd like to hear others views on the topic. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev