<font face="&#39;courier new&#39;, monospace">Hi Alexandros,<br><br></font><span style="font-family:&#39;courier new&#39;,monospace">Looks good overall.</span><div>
<font face="&#39;courier new&#39;, monospace"><br>But there&#39;s one detail I&#39;d prefer see done differently: it&#39;s better not to introduce this reverse/cyclic dependency from glproc to glws. glproc should be self-sufficient, and the code organized in the following layers:<br>

<br>  (e)glimports  // type definitions<br>   |<br>   V<br>  glproc        // dynamic binding of the entrypoints<br>   |</font><div><font face="&#39;courier new&#39;, monospace">   V<br>  glws          // window system abstraction<br>

   |</font></div><div><font face="&#39;courier new&#39;, monospace">   V</font></div><div><font face="&#39;courier new&#39;, monospace"> (e)glretrace   // actual application<br>
<br>The <a href="https://github.com/apitrace/apitrace/tree/glproc-cleanup">https://github.com/apitrace/apitrace/tree/glproc-cleanup</a> takes some of your changes but obverses the above scheme.  There&#39;s more stuff I wanna do in glproc, but it&#39;s a good step. I&#39;ve already tested it on Linux/MacOSX/Windows, so if it doesn&#39;t regress Android for you I&#39;ll merge it.<br>
<br><br></font></div><div><font face="&#39;courier new&#39;, monospace">Jose</font><br style="font-family:&#39;courier new&#39;,monospace"><font face="&#39;courier new&#39;, monospace"><br>
</font><br>On Thu, Dec 1, 2011 at 4:52 PM, Alexandros Frantzis &lt;<a href="mailto:alexandros.frantzis@linaro.org" target="_blank">alexandros.frantzis@linaro.org</a>&gt; wrote:<br>&gt; Hi all,<br>&gt;<br>&gt; in the spirit of what was previously discussed, I am working on a branch<br>

&gt; that implements a scheme allowing the retracers to avoid explicitly<br>&gt; linking with libGL:<br>&gt;<br>&gt; <a href="http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/retrace-no-link-gl-wip" target="_blank">http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/retrace-no-link-gl-wip</a><br>

&gt;<br>&gt; This patchset first adds a glws::getProcAddress() function that<br>&gt; implements the logic to get a GL/EGL/... function pointer, by first<br>&gt; trying the system mechanism for getting symbol addresses (dlsym etc),<br>

&gt; and then by using the *GetProcAddress() functions.  The implementation<br>&gt; for each system is based on the snippets in *trace.py. The code retains<br>&gt; the approach of first searching in the already linked libraries and<br>

&gt; then, if needed, trying to dlopen() the right GL library.  For the<br>&gt; EGL/X11 case, the right library is selected based on the current<br>&gt; context/profile. I have added sample implementations for Cocoa and<br>

&gt; Win32, too, but as I don&#39;t have access to such systems, these two are<br>&gt; completely untested.<br>&gt;<br>&gt; The patchset also changes the way glproc.hpp is produced for retracing.<br>&gt; In particular, it emits __* dispatchers for *all* processed functions,<br>

&gt; and uses the glws::getProcAddress() function to get the address of both<br>&gt; &quot;public&quot; and &quot;private&quot; symbols. Due to the way glws::getProcAddress()<br>&gt; works, the &quot;private&quot; vs &quot;public&quot; distinction does not make much sense.<br>

&gt;<br>&gt; Finally, the patchset ensures that eglretrace doesn&#39;t explicitly link<br>&gt; with libGL, and that any needed libraries are indeed linked with (i.e.<br>&gt; marked as NEEDED in the SO) even when none of their symbols are<br>

&gt; explicitly used. This is important primarily for libEGL at the moment.<br>&gt; Of course, if we choose to do so, we can handle libEGL in the same way<br>&gt; that we handle libGL, i.e., not require explicit linking.<br>

&gt;<br>&gt; Note that, besides a small fix for proper compilation, the need for<br>&gt; different state dumping mechanisms for GLX/GL vs EGL/GL* is not<br>&gt; addressed at all by this patchset.<br>&gt;<br>&gt; Thanks,<br>

&gt; Alexandros<br>&gt; _______________________________________________<br>&gt; apitrace mailing list<br>&gt; <a href="mailto:apitrace@lists.freedesktop.org" target="_blank">apitrace@lists.freedesktop.org</a><br>&gt; <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>

</div></div>