On Fri, 24 Mar 2000, Thomas Roell wrote:
> We have found lately an issue that the OGLBASE does not address
> properly, but it's still an issue.
I agree that there is a problem - but I don't think it's an
issue for OGLBASE to solve.
In general, how does a versioning library system cope with
the concept of a "better but older" library. That's not a
unique problem though. I had this a couple of days ago when
I wanted to install a specific version of SDL that was older
than the one that SuSE Linux had installed because it lacked
a bug that's present in SuSE's current version.
It was a devil of a problem to get RPM and YAST to do what I
wanted and not what it wanted...and worse still, every time
I tell YAST to update my machine with the latest versions
of everything, it'll screw it up for me once more.
So, I don't think this is an OGLBASE issue - although I do
feel your pain.
> 1. We ship of 1.2 based library, and simply call it libGL.so.1.2.0.
> Doesn't really address the problem, as there will be a Mesa based
> library called libGL.so.1.2.1, and the same old problem will be
> there.
Indeed.
> 2. Simply remove the current exisiting libGL.so at installtime.
> Well, this is subobtimal as well, as then if a user wants to go
> back to the original version, then where to get the original
> library from ?
Well, you can always rename it or something...but that's rather
dangerous.
What's worse though is that when your user gets a new version of
his favorite Linux distro and hits the auto-update button, it'll
see Mesa as being more recent than your library and dump it again.
> The issue goes deeper with the include files in /usr/include/GL as
> well. It's understood that gl.h and glx.h should be interchangeable,
...not if Mesa's gl.h has to define GL_VERSION_1_2 and your libGL.so
only supports OpenGL 1.1. Mesa *must* have that symbol defined and
OpenGL 1.1 implementations must not. It's hard to see how you'd
resolve that short of replacing the Mesa headers with your own.
> ...but for simple support reasons it would be nice to install the ones
> that came with the libGL.so (this might be a future OpenGL 1.3
> vs. OpenGL 1.2 issue as well).
Yep.
> My question is how to handle those scenarios. The are really BIG
> issues for everybody shipping a driver or a complete libGL.so, as
> there are always versioning problems.
Yep - those are certainly a problem - but not for this specification.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
