Re: [Libvisual-devel] GL library linkage

[Vitaly V. B. <vit...@us...>]

On Fri, 15 Oct 2004 13:27:26 +0200
Burkhard Plaum <pl...@ip...> wrote:

> > This is worst case scenario. If you need to intermix different contexts,
> > you group gl calls anyway, don't you?
> 
> I wouldn't intermix the calls, because it's nonsense.
> But as I said, less advanced programmers get strange ideas,
> when nobody watches them :-)
:) so as more advanced.

> > If there is malloc()'ed struct with dlsym()'ed function pointers,
> > call is like this
> > 
> > 	mov <struct address>(,%index_reg,4), %eax
> > 	call *%eax
> > 
> > or something alike.
> 
> And this would be the case, if you would wrap dlsym()ed gl* functions into
> lvgl* calls?
Yes.

Here are test results.

optimization is off.
$ gcc -g a.c

=======
int main()                                                                      
{                                                                               
    void *h = dlopen("libm.so.6", RTLD_LAZY);                                   
                                                                                
    a = dlsym(h, "sin");                                                        
    a(0.3);                                                                     
}
=======

piece of asm code.

// it's a a(0.3) call;
0x08048432 <main+58>:   mov    %eax,0x8049668
0x08048437 <main+63>:   movl   $0x3e99999a,(%esp)
0x0804843e <main+70>:   mov    0x8049668,%eax
0x08048443 <main+75>:   call   *%eax
0x08048445 <main+77>:   fstp   %st(0)

(gdb) stepi
0x0804843e      10          a(0.3);
(gdb) 
0x08048443      10          a(0.3);
(gdb) 
0x41156760 in __sin () from /lib/libm.so.6
(gdb) print /x $eax
$3 = 0x41156760


> >>If the usage of multiple OpenGL libs cannot be avoided:
> >>Would it make sense to have them in separate processes? The LD_PRELOAD
> >>environment variable can easily force a certain libGL.so to be used,
> >>and OpenGL can be used as we learned it.
> > 
> > That's too drain bamaging, sorry :)
> 
> IMHO less brain damaging than renaming and wrapping 100s of OpenGL
> functions.
Hm, it is possible to not rename them. just declare these glAsdFg()
functions. One problem here is that if plugin gets linked to
libGL.

> > So, as I wrote above, there is almost no difference between staticaly
> > shared linkage and dlopen()'ed libraries regarding to speed.
> > Is it OK to load dynamically libGL?
> 
> There are now 3 options:
> 
> 1. Link statically
> 2. Link dynamically
> 3. dlopen
> 
> Which of 1 and 2 are used, is beyond control of the libvisual developers.
> Because it depends on which libs (.a or .so or both) the user has installed
> when compiling. Normally, the linker will perfer .so until -static is used.

> So the question is whether to link opengl (i.e. -lGL) or dlopen() it.
> I strongly believe, that linking is easier, it's the standard way to use
> libraries and causes little overhead (and the burdon of making this
> work is transferred to the gcc/glibc/kernel developers).
... various X Servers, various GL drivers, various venders.
And everybody has own opinion.

> Furthermore, if some new functions appear in a later OpenGL version,
> plugin developers can play with them without waiting, until a new libvisual
> version makes them available through dlsym().
This can be done automatically during build process. If there's a header
file with declarations it's possible to parse it.

And how should be handled plugins that dlopen() libGL? (hm, are there any
around? except scivi, of course :))

Dennis, what do you think? We have a Holy War here! :)

-- 
Vitaly
GPG Key ID: F95A23B9