Re: [Libvisual-devel] GL library linkage

[Dennis S. <sy...@yo...>]

On Tue, 2004-10-19 at 22:33 +0300, Vitaly V. Bursov wrote:
> > 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.

> > 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.

What about binear distributions of libvisual ?

> 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! :)

Well, I must admit I haven't been following it all, can you summarise 
what the advantage is off dlopen is, and what the problems are with
dynamical linking ?


I'd personally go for dynamical linking as long that is possible, when
problems arise, we shouldn't go out of the way, and do it the hard way
if needed, but only if needed.

Cheers,
Dennis