Re: Problems with latest back and base

[Frederic De Jaeger]

JT> In QuakeForge, we solved most of our OpenGL problems by creating our own
JT> set of OpenGL headers, never using the system's, and never linking with
JT> libGL (instead, loading the library dynamically and connecting the gl*
JT> functions to function pointers that are available at build-time).

JT> The last is of particular importance on Linux, where certain vendors link
JT> their libGL to external libraries which are only provided by them.
JT> Programs and libraries linked in such a way can *only* be used on systems
JT> using the same libGL that was present at link-time.

JT> NVIDIA's libGL is one of these. ATI's closed-source libGL may be
JT> also.

This is not really true because ELF format is smart enough to not
propagate dependencies at link time.  NVidia's libGL.so depends on
their own libGLcore.so, that's true.   But a program compiled on such
system should word perfectly well on another system with another GL
library (one without a libGLcore.so) if, of course, you are not using
NVidia's internals.

JT> This also gave us the ability to build OpenGL-using programs without
JT> actually having OpenGL support on the systems that were doing the
JT> build.

This is a better reason.  That's why I thought, at the beginning, to put
all the GL stuff in a separate bundle.  So that, the backend would
not depend on GL.
Anyway, it is only four lines of code to revert to this architecture
(Thanks to objective-C and bundles)

I don't have a lot of time to improve the GL support of the backend
right now (finishing a phd thesis).  But is should change soon.

Cheers,

        Frederic De Jaeger