RFC/WIP: Retracing without explicitly linking to libGL

[José Fonseca]

Hi Alexandros,

Looks good overall.

But there's one detail I'd prefer see done differently: it'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:

  (e)glimports  // type definitions
   |
   V
  glproc        // dynamic binding of the entrypoints
   |
   V
  glws          // window system abstraction
   |
   V
 (e)glretrace   // actual application

The https://github.com/apitrace/apitrace/tree/glproc-cleanup takes some of
your changes but obverses the above scheme.  There's more stuff I wanna do
in glproc, but it's a good step. I've already tested it on
Linux/MacOSX/Windows, so if it doesn't regress Android for you I'll merge
it.


Jose


On Thu, Dec 1, 2011 at 4:52 PM, Alexandros Frantzis <
alexandros.frantzis at linaro.org> wrote:
> Hi all,
>
> in the spirit of what was previously discussed, I am working on a branch
> that implements a scheme allowing the retracers to avoid explicitly
> linking with libGL:
>
>
http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/retrace-no-link-gl-wip
>
> This patchset first adds a glws::getProcAddress() function that
> implements the logic to get a GL/EGL/... function pointer, by first
> trying the system mechanism for getting symbol addresses (dlsym etc),
> and then by using the *GetProcAddress() functions.  The implementation
> for each system is based on the snippets in *trace.py. The code retains
> the approach of first searching in the already linked libraries and
> then, if needed, trying to dlopen() the right GL library.  For the
> EGL/X11 case, the right library is selected based on the current
> context/profile. I have added sample implementations for Cocoa and
> Win32, too, but as I don't have access to such systems, these two are
> completely untested.
>
> The patchset also changes the way glproc.hpp is produced for retracing.
> In particular, it emits __* dispatchers for *all* processed functions,
> and uses the glws::getProcAddress() function to get the address of both
> "public" and "private" symbols. Due to the way glws::getProcAddress()
> works, the "private" vs "public" distinction does not make much sense.
>
> Finally, the patchset ensures that eglretrace doesn't explicitly link
> with libGL, and that any needed libraries are indeed linked with (i.e.
> marked as NEEDED in the SO) even when none of their symbols are
> explicitly used. This is important primarily for libEGL at the moment.
> Of course, if we choose to do so, we can handle libEGL in the same way
> that we handle libGL, i.e., not require explicit linking.
>
> Note that, besides a small fix for proper compilation, the need for
> different state dumping mechanisms for GLX/GL vs EGL/GL* is not
> addressed at all by this patchset.
>
> Thanks,
> Alexandros
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20111201/06da7358/attachment.htm>