[vtk-developers] extension wrangler

[Moreland, Kenneth]

Whether or not VTK is compiled static or dynamic is immaterial.  A static build can still link against a shared OpenGL library (and call dlopen on it) and a dynamic link might still be using a static OpenGL library.
 
The problem is, it is hard to accurately pick exactly which library file a linker is going to link against.  We were running into problems where we identified a shared OpenGL library that probably should have been used, but the linker was using a different library.  And if the binaries are moved to a different machine, the whole thing can break down.
 
If there was a way to query at runtime what shared objects were loaded, identify which one was OpenGL, and then call dlopen on that, that would probably work.  However, I don't know of any way to do that query.
 
-Ken

________________________________

From: Jeff Lee [mailto:jeff at cdnorthamerica.com]
Sent: Tue 11/15/2005 2:17 PM
To: Moreland, Kenneth
Cc: vtk-developers
Subject: Re: [vtk-developers] extension wrangler





Moreland, Kenneth wrote:

> The dlopen technique was dissabled because it was proving to be
> unreliable.  Some of VTK's dashboard tests were continually failing
> because VTK was being compiled against one OpenGL library (which
> happened to be static) and the dlopen was openening a shared object
> library elsewhere.  Thus, it would look like the extension was loaded
> correctly, but the application would crash if you tried to use any of
> the functions.
>
What if the dlopen method were only enabled when vtk is built shared?  I
saw that vtkOpenGLExtensionManagerConfigure.h that does
#define OPENGL_LIBRARIES
"/usr/lib/libGL.so;-lSM;-lICE;-lSM;-lICE;/usr/X11R6/lib/libX11.so;/usr/X11R6/lib/libXext.so;/usr/X11R6/lib/libX11.so;/usr/X11R6/lib/libXext.so"

If you do dlopen with a null in the first argument, the loader will
search the libpath (you don't really need to specify).  Is this the kind
of behavior we should support?  Are there cases when this approach
yields undesirable results?  This appears to be what glew does.
Regards,
-J

>
> Ultimately we could not figure out a way to ensure that the dlopen
> tried to open the same library that was already being used. (The
> problem gets more compilicated when you compile on one machine and run
> on another.) If someone could solve this problem, then the dlopen
> method would work just fine.
>
> -Ken
>
>
> -----Original Message-----
> From: vtk-developers-bounces+kmorel=sandia.gov at vtk.org on behalf of
> Jeff Lee
> Sent: Tue 11/15/2005 12:31 PM
> To: vtk-developers
> Subject: [vtk-developers] extension wrangler
>
> Hi,
> Does anyone know why the extension wrangler in vtk has the fallback
> dlopen technique disabled?  Is there some way this could be fixed for
> systems without glxProcAddressARB functionality?  Is the wrangler meant
> to be a runtime wrangler, or just compile-time?
> Regards,
> Jeff
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>

--
Jeff Lee
Senior Software Engineer
Computational Dynamics North America Ltd
21 Lafayette Street, Suite 230
Lebanon NH 03766 USA
fax:   603 643 9994
phone: 603 643 9993 x109
http://www.cd-adapco.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20051116/725abff4/attachment.html>