On Mon, Feb 14, 2000 at 01:56:07PM -0700, Brett Johnson wrote:
> To make my position clear: Of the three solutions given so far to this
> problem, I think #3 (above) is the most likely to succeed. Given that
> we're trying to define an ABI though, I think that #2 is the next best
> alternative. #1 just won't work. I'm open to any other solutions. I'm
> also open to just noting this as an issue and moving on.
A big transition in Linux 3D is happening, and such transitions are
the best time to allowing breaking compatibility - if enough of the
driver suppliers agree. I think we have critical volume here, if we *do*
agree. It may be a problem for ISVs and end users, but I don't know how
it could possibly be any more of a problem than the fact that there *is*
no ABI today, or other issues like the driver install / "GLSetup" stuff
that Bernd describes.
We might help to alleviate the problem by writing a sanity checker
which examines a binary app and proclaims it (likely to be) ABI
compliant or not; this could just be a script which runs ldd and such on
the app, or maybe include an actual minimal reference driver
(stubbed-out libGL?) and runs through app startup and initial context
creation.
> The only thing I can think of that makes libGL "special" is that we're
> trying to define binary compatibility between different vendor's
> implementations of libGL.so. None of the other libraries you've mentioned
> have such a definition, so they don't have this problem.
I disagree. Notably, there are multiple X implementations on Linux,
including commercial servers and the many versions of XFree86 out there.
Jon Leech
SGI
