Jon Leech wrote:
> 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.
This seems like a reasonable approach. For those ISVs that are willing
to support the ABI effort, the "reference driver" would provide an easy
way to test their app for this problem. I like it.
> > 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.
X is a different beast altogether. The X server isn't a library, so it
obviously doesn't have this problem. And, AFAIK, none of the X server
vendors actually replace your xfree86 libraries with their own proprietary
ones, so the libraries don't have the problem either.
The one exception that I can think of to this rule is motif. There are
several commercial motif libs out there, and there is also lesstif. This
isn't a problem for them, because the only library any of them have transitive
links to is libc (or glibc, depending on the version). So, in effect, they
have the same restriction I was talking about earlier. If one of them were
to include a link to libXt, for example, I could almost guarantee that
most of the apps compiled against that version would be broken with any of
the other versions because of this issue.
I think that because of its complexity, libGL.so is somewhat unique in this
respect. Due to this complexity, the various implementations of libGL are
likely to be implemented quite differently internally, and require different
runtime support. I can't think of any other shared library where all of
these issues coincide.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
