Brian Paul wrote:
>
> Brett Johnson wrote:
> > 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.
>
> I'm very surprised to hear that you can't have -lICE in your
> app link command. Listing the same library twice (even if once
> is an indirect occurance) shouldn't cause an error.
It doesn't cause an error. All I said was that many apps won't bother
to resolve their own dependencies this way. If the app works without
resolving them (since all the symbols are resolved through Mesa, and
everything works just fine under Mesa), it's pretty easy for the ISV
to not bother tracking down all of the symbols they "should" be
resolving directly on their own link line. It's particularly easy if
the ISV is small, and doesn't have the resources to test the app on
a wide variety of libGL implementations.
[list of libraries elided...]
> That list is way too long. I don't know how you're getting C++
> libs in there.
You're right, the c++ libs shouldn't be in libGL. They will likely
need to there for libGLU though, as any libGLU based on the SI will
have C++ dependencies.
> Also, a number of them, like Xmu, XI, Xt, are
> only needed because of GLUT.
That may be true, but they're still included as transitive links in
Mesa's libGL.so. As a result, many applications that are compiled
against Mesa won't run against any other libGL unless the other libGL
also provides transitive links to Xmu, Xi and Xt.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
