[Mesa-dev] [RFC PATCH] GBM: Add map/unmap functions
robh at kernel.org
Tue May 24 00:31:22 UTC 2016
On Mon, May 23, 2016 at 7: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: 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.
Yeah, that's what I had started trying too...
> 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.
The first sounds nice, but can you do weak functions in a header?
You'd get a weak function with every include of the header I think.
More information about the mesa-dev