<div dir="ltr"><br><div class="gmail_extra">On Mon, Aug 11, 2014 at 6:04 AM, Søren Sandmann <span dir="ltr"><<a href="mailto:soren.sandmann@gmail.com" target="_blank">soren.sandmann@gmail.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thread local storage is when a C variable is marked with "__thread" as<br>
being local to a thread. Pixman has an internal cache that relies on<br>
this mechanism working. On compilers/systems where thread local storage<br>
doesn't work, you'll get the above message.<br>
<br>
Since you are using a Beta compiler, broken thread local support is<br>
definitely my first suspicion. One thing you might try is changing<br>
<br>
    #define N_CACHED_FAST_PATHS 8<br>
<br>
to<br>
<br>
    #define N_CACHED_FAST_PATHS 0<br>
<br>
in pixman-implementation.c. That probably will fix the issue at a<br>
potentially significant loss of performance.<br>
<span class=""><font color="#888888"><br>
Søren<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Thanks for the explanation. This prompted me to check the compiler<br>options and there is a '-xthread' option for controlling local thread<br>storage; it has an optional string following it to control whether one<br>
is compiling PIC or not.<br><br></div><div class="gmail_extra">Unfortunately compiling with -xthread (defaults to -xthread=dynamic),<br></div><div class="gmail_extra">produced no change in the clip-test program---still complains about<br>
'No composite function found'.<br><br><br><br></div><div class="gmail_extra">Also, it isn't possible to set the above macro to zero as this<br>is used as the length of an array  in the cache_t type and the<br>
compiler complains about a zero subscript.<br><br></div><div class="gmail_extra">Noel Hunt<br></div></div>