ABI Draft:
> 3.8. libGL and libGLU must be transitively linked with any libraries
> they require in their own internal implementation, so that applications
> don't fail on some implementations due to not pulling in libraries
> needed not by the app, but by the implementation.
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.
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. As long as the
app links against Mesa, it's libICE dependencies will be resolved
through Mesa's transitive link.
Unfortunately though, this means that this app cannot run against
any other libGL.so, unless the all other libGL's also provide this
same link. So, all libraries must provide exactly the same set of
transitive links, if we are to achieve actual binary compatibility
between them.
As a start, I'd like to suggest that we publish a "standard" set
of libraries that all libGL's should transitively link against. As a
strawman, I'll propose that this be the set of libraries that Mesa's
libGL.so links against (as it's a pretty comprehensive set ;):
libdl.so.2
libXext.so.6
libXmu.so.6
libXi.so.6
libXt.so.6
libvga.so.1
libSM.so.6
libICE.so.6
libg++.so.2.7.2
libstdc++-libc6.1-1.so.2
libm.so.6
libc.so.6
ld-linux.so.2
libX11.so.6
libstdc++.so.2.7.2
Does anyone's libGL have any dependencies that aren't addressed
here?
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
