apitrace on OS X

Peter Lohrmann peterl at valvesoftware.com
Tue May 28 18:19:59 PDT 2013


We have tracked down the issue regarding the DYLD_LIBRARY_PATH approach to being that the apitrace OpenGL wrapper does not expose some of the CGL entrypoints which are required by one of the other system frameworks that we are using. In the apitrace\specs\cglapi.py script, the entrypoints at the bottom marked with #FIXME are those causing the problem, which unfortunately are undocumented publicly.

I'll see what I can dig up from other resources.
- Peter

From: José Fonseca [mailto:jose.r.fonseca at gmail.com]
Sent: Saturday, May 25, 2013 12:43 AM
To: Peter Lohrmann
Cc: Apitrace list
Subject: Re: apitrace on OS X

I'm surprised DYLD_INSERT_LIBRARIES/DYLD_FORCE_FLAT_NAMESPACE works at all. I don't fully understand the impact of DYLD_FORCE_FLAT_NAMESPACE but non-trivial apps failed when I set it.

One thing to bear in mind is that OpenGL API in Mac OSX is composed by nested dynamic libraries:  (this is from memory) there is a OpenGL.dylib which has a few entrypoints, and then depends on libGL.dydlib for most GL entrypoints, and libGLU.dylib too.

I think your best bet is debugging why DYLD_LIBRARY_PATH does not work. You could set DYLD_PRINT_* debugging env vars like DYLD_PRINT_BINDINGS, with and without apitrace, and then analyse the differences in the logs.

apitrace has always worked well for me on OSX, but I only use it with a select number of apps. I'd not be surprised if there are some corner case in OSX that we don't handle. Similar issues have happened with other platforms, and it took several iterations to handle them.

For the record, there might be other ways to inject into MacOSX OpenGL stack -- I suspect that tools like CHUD OpenGL Profiler inject straight into internal dispatch tables, but I never spent time investigating how, as the apitrace injection worked well for me as is.

Jose
On Sat, May 25, 2013 at 1:06 AM, Peter Lohrmann <peterl at valvesoftware.com<mailto:peterl at valvesoftware.com>> wrote:
Now that I've got everything compiling correctly, I'm experiencing other issues that hopefully someone has encountered and knows a workaround for. I've been able to successfully use apitrace on a simple sample app (OSXGLEssentials), but am encountering other issues when trying trace a more complicated app.

if I use the recommended DYLD_LIBRARY_PATH approach, the app fails to load other libraries and doesn't run (I will investigate this issue, as its likely something simple). If I use DYLD_INSERT_LIBRARIES and DYLD_FORCE_FLAT_NAMESPACE=1, the application runs correctly and generates a trace file, but only CGL calls are recorded into the trace and none of the gl* calls. Any suggestions?

Thank you all,
Peter

From: José Fonseca [mailto:jose.r.fonseca at gmail.com<mailto:jose.r.fonseca at gmail.com>]
Sent: Tuesday, May 14, 2013 11:13 PM

To: Peter Lohrmann
Cc: Apitrace list
Subject: Re: apitrace on OS X



On Wed, May 15, 2013 at 1:54 AM, Peter Lohrmann <peterl at valvesoftware.com<mailto:peterl at valvesoftware.com>> wrote:
Looks like the library I was generating was x86_64, but the application was strictly i386.  It took a bit of messing around with the project settings to get it to output just a 32-bit version, and then it seems the generated library went to a different directory /ApiTrace/build/wrappers/Debug instead of /ApiTrace/build/Debug/wrappers.
That's peculiar, as CMakeLists.txt should have built both architectures:

  # On Mac OS X build fat binaries with i386 and x86_64 architectures by default.
  if (APPLE AND NOT CMAKE_OSX_ARCHITECTURES)
      set (CMAKE_OSX_ARCHITECTURES "i386;x86_64" CACHE STRING "Build architectures for OSX" FORCE)
  endif ()

What XCode version did you use? Did you use cmake and make to build from commandline, or something different?

Jose

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20130529/c0b96fc3/attachment.html>


More information about the apitrace mailing list