No dlopen() (was: Error with dlopen on linux 64 bit)

[José Fonseca]

I intend to intercept dlsym instead.

(At least on Linux with glibc, where we have mechanisms to get the real
dlsym even when we define our own without failling into an inifinite
recursion.  On Android we'll probably need to continue to intercept dlopen
and hope for the best.)

But don't worry, dlsym(dlopen("libGL.so.1"), "glXxxx") will continue to
work, one way or the other.

The objective here will be handle better corner cases; e.g. where the app
does dlopen("libGL.so.1", RTLD_LOCAL), or when the IHV's EGL/GL driver does
dlopen("libEGL.so" and segfaults when it fails to find internal symbols in
our wrapper.

Jose

On Mon, Nov 16, 2015 at 11:06 PM, <io.github.apitrace at io7m.com> wrote:

> On 2015-11-16T21:10:44 +0000
> José Fonseca <jose.r.fonseca at gmail.com> wrote:
>
> > I plan to update apitrace to not intercept dlopen -- it causes more
> > problems than it solves.
> >
> > Jose
>
> 'Lo.
>
> May I ask what you intend to do instead? I may be unnecessarily
> fearful, but I use apitrace to trace JOGL programs (Java programs using
> the JOGL bindings). I suspect (but may be entirely wrong) that apitrace
> works well there precisely because the JOGL bindings call dlopen() on
> libGL.so and apitrace correctly intercepts the call.
>
> I would hate to find that apitrace was updated in a manner that stopped
> it working for Java OpenGL programs.
>
> M
> _______________________________________________
> 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/20151117/1ad5a96a/attachment.html>