[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with latest back and base
From: |
Frederic De Jaeger |
Subject: |
Re: Problems with latest back and base |
Date: |
16 Jan 2003 12:19:19 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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