In your message of 15 February 2000 you write:
> On Mon, 14 Feb 2000, Jon Trulson wrote:
>
> > Hmm. I though the whole point of the Linux/OGL base was to create
> > that compatibility... Certainly our OGL only links what it specifically
> > needs... An easy way to find these types of things is simply (in your
> > case) link a static version of Mesa into your app... The linker will tell
> > you what you need ;-)
>
> Well, as I see it there are only three choices:
>
> 1) The ABI specifically limits which libraries libGL can reference
> so that the application can link to them all - and hence function
> with every OpenGL on the planet.
>
> OR:
>
> 2) The ABI requires libGL to be pre-linked against every library
> it needs - and hence it will function no matter what the
> application links to.
>
> OR:
>
> 3) The ABI lists a minimum set of libraries that all OpenGL
> applications should link to - and requires libGL to be
> pre-linked against any additional libraries it might need.
> (Kind of a pragmatic blend of (1) and (2))
The last alternative would be tricky, as different libGL.so
implementations would need different libraries to reference.
A libGL.so that uses libdl.so to load renderer support needs of course
libdl.so. Another implementation might use rendering deamons an not
use libdl.so. To make things worse, what if you have a libGL.so that
is using C++ code, and might need libstdc++ ?
A way of handling that mess is to require the implementator of a
specific libGL.so to implicitely reference ALL libraries that are
needed to let libGL.so/libGLU.so resolve it's own unresolved symbols.
For a typical implementation this might be
libX11.so/libdl.so/libm.so/libc.so.
However the view an application write has is that libGL.so does not
reference ANYTHING. So if you have apps that require libX11.so, they
have to link against it.
To allow an apps to verify it's compliance is to simply link against a
static version of libGL.
> I vote for option (3). We say that all ABI-compliant OpenGL
> applications must link to some sensible set of libs that
> most OpenGL's are likely to be happy with (say):
>
> -lX11 -lXi -lXext -lXmu -lm
>
> ...and of course, libc. (That may not be *exactly* the
> right list - but we can debate what that list should be if
> the principal of the thing is ever agreed - IMHO, that list
> should contain everything that Mesa and current known Linux
> OpenGL's need).
I'm here a little bit more minimalistic. libX11/libXext ok. Althought
purists will say that it's perfectly fine to have a libGL that does
not need X11/GLX. libXmu ... no. Those are miscellenous X11 utility
functions outside of the regular X11. Same things goes with
libXi. This one handles only additional input devices. I'm perfectly
fine with this list (+/- link-oder issues), although I'm more
minimalistic. I stronly oppose to have libXt or anythin above the
upper list in a requirements list.
> Then, if libGL or libGLU depend on anything *else* then they must
> be pre-linked to whatever additional things they need.
So if my libGL.so would not have to implicitely reference libX11.so or
libXext.so ?
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
