On Tue, Mar 12, 2013 at 8:21 AM, Alexander Monakov <span dir="ltr"><<a href="mailto:amonakov@ispras.ru" target="_blank">amonakov@ispras.ru</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
On Tue, 12 Mar 2013, Shuang He wrote:<br>
<br>
> Hi,<br>
>     Just realized that apitrace may affect code path of 3D application, since<br>
> 3D application may try different ways to probe for supported GL extension. One<br>
> way would be dlsym()<br>
<br>
</div>Such application would be ignoring the OpenGL ABI.<br>
<br>
In any case, such application must consult extension strings before actually<br>
using the functions it obtained via dlsym, otherwise it has no possible way of<br>
knowing if they will actually work.<br></blockquote><div><br></div><div>Precisely.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But yes, the world is not perfect, and there are applications that probe libGL<br>
with dlsym and also ignore extension strings.<br></blockquote><div><br></div><div>Apps that make such mistake may indeed exist, but I believe they must be relatively rare as they would break in so many cases other than apitrace, as having more symbols than supported entrypoints is quite common (Mesa drivers, indirect GLX, MacOSX, etc).  So I don't see a reason to go out of our way to cater for them.  If/when such app appears, then my suggestion would be to make a custom build of apitrace that hid any symbol that was confusing the app. </div>
<div><br></div><div>Jose</div></div>