apitrace on OS X

[José Fonseca]

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>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]
> *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>
> 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/20130525/73950283/attachment.html>