On Sat, Jun 15, 2013 at 8:05 PM, Carl Worth <cwo...@cworth.org> wrote:
> José Fonseca <jfons...@vmware.com> writes: > > FYI, with > > > https://github.com/apitrace/apitrace/commit/7700f74f294a28e57860487b917c8807156b3ad1 > > apitrace no longer crashes with Steam overlay. > > Thanks, José! This will be quite handy. And it's a fix I'd been hoping > to make for apitrace, but hadn't gotten around to. > > It's also nice to see that you got __libc_dlsym working. When I wrote a > similar dlsym wrapper for fips I think I tried that but didn't get it to > work for some reason. (I ended up with something that feels more fragile > by calling dlvsym to find "dlsym".) So I'll revisit this with the > apitrace code in mind. > > > But the overlay's rendering is not shown/captured when when apitrace > > uses LD_PRELOAD. > > Do you know why this is? > No, I don't have a clear understanding. There are many ways where multiple LD_PRELOAD objects can interfere with each other (beyond the problem found). If all preload .so did dlsym(RTLD_NEXT, "foo") then they would probably nest safely. But given we need to intercept dlsym and/or dlpen, plus functions like glxGetProcAddress. Even if they nested properly, depending on the ordering of apitrace vs overlay one might get the overlay working but not actually recorded on file. But I get the feeling that something is triggering the Steam overlay to not activate at all. > I'd definitely be interested in making apitrace work more transparently here. Me too. But there are so many apps that only work well with LD_LIBRARY_PATH, that make think that the best way forward is not to keep adding hacks for LD_PRELOAD to work, but rather making apitrace seemingly use LD_LIBRARY_PATH out of the box. Jose
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
