[Mesa-dev] [RFC PATCH] GBM: Add map/unmap functions

[Rob Clark]

On Mon, May 23, 2016 at 8:12 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 23 May 2016 at 22:19, Rob Clark <robdclark at gmail.com> wrote:
>> On Mon, May 23, 2016 at 5:16 PM, Mark Janes <mark.a.janes at 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.

fwiw, Ben had a pthreads-stubs patch to fix this, which can hopefully
get pushed and made into a release soonish, although not sure if we
want to sit around and wait for that since this is kinda a big pita
(and maybe even an issue for alternate compilers?)

In this kinda situation, I'm all for a temporary ugly solution if
there isn't an elegant one ;-)

BR,
-R

> Thanks
> Emil