Jon Leech wrote:
>
> On Mon, Feb 14, 2000 at 11:30:37AM -0700, Brett Johnson wrote:
> > I think this section should be changed. Requiring libraries to resolve
> > their own internal dependencies is a start, and certainly should be
> > required. But this isn't sufficient, in that it ignores the larger
> > issue of compatibility between libraries when an app doesn't explicitly
> > resolve it's own dependencies.
>
> Such an app is clearly broken and deserves the consequences, IMO.
I share your views on this Jon. I wish that all app writers were careful
and would think about compatibility issues before releasing binaries. I
posted this because in my experience so far, about 80% of the apps & games
that we have run against our OpenGL implementation have been broken in this
way. If we really want to achieve binary compatibility between OpenGL
libraries, we have to deal with this problem. I can see three possible
ways to deal with it:
1) Require all apps to resolve their own dependencies. This is obviously
the "right" answer from a technical standpoint. From a practical and
political standpoint though, I don't think it has much of a chance of
being successful. It would surprise me greatly if 10% of app writers
will even look at the ABI spec, much less heed it. Trying to mandate
"good citizenship" to all app writers is doomed to fail.
2) The requirement I proposed before, where all libGL's must link against
a common set of libraries. This obviously sucks from a technical
standpoint, and I don't really like it any more than you or anyone else
that has responded. Practically though, it's a reality that will have
to be faced, given the current direction of Linux 3D. I know that we
(HP) aren't about to release a libGL that 80% of existing apps won't
run on, so we have to fix this problem from our end (by redundantly
linking against everything that Mesa does). I suspect that other
implementors will have the same problem.
3) Give up on the idea of defining a true binary-compatible spec, and
let the free market define a defacto ABI standard (i.e Mesa), which
all other implementations will adhere to due to market pressure.
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.
> > For example, if an app compiles against the Mesa libs, it doesn't
> > need to (and likely won't) explicitly link itself against libICE.so,
> > even if the app depends on libICE.so entrypoints.
>
> Why should every libGL in the oglbase world should be responsible
> for transitively linking against every library linked against by every
> other libGL in the world? Why is there something special about libGL
> that makes it any more subject to such an onerous requirement than, say,
> glibc or libXmu or any other system library commonly used by the
> application?
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.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
