On Thu, Oct 18, 2001 at 10:20:37AM -0700, Billy Biggs wrote:
> Sottek, Matthew J ([EMAIL PROTECTED]):
> > use libXv.so to hide the uglies and if you don't want a software
> > fallback then you don't have to have one.
>
> I sure hope you're distributing it as a .so then. On my debian system
> it's just distributed as a static lib.
>
> Nasty situation...
Funny you should bring that up.
I'd like to solicit opinions, especially from the Core Team, about the
shared vs. static extension library situation. Debian just went through
a bit of pain and suffering as regards SDL in our development branch,
partly because we have 12 architectures to supprt for our next release.
A quick recap, as I understand it:
1) In XFree86 4.1.0, extension libraries like libXxf86dga, libXxf86vm,
and libXv are built only as static objects by default. (In English,
these represent the client-side libraries for the DGA, VidMode, and
XVideo extensions.)
2) When you build something as a static object only, you don't have to
worry (at least not as much) about incompatible interface changes
because every client has its own copy of the library, and is guaranteed
to be able to resolve the library's symbols.
3) On some architectures, like IA-64, PA-RISC, PowerPC, MIPS (both big
and little-endian varieties), and Motorola m68k, at least under Linux
using the GNU toolchain, it is not legal to link a static object into a
shared one. Static objects don't have symbol relocation data and the
linker demands this information to create a shared object. On other
architectures, most notably x86, this is legal. (I don't know what
hoops either the linker or object loader jump through to make this
possible.)
4) You can make the problem "go away" on Linux with gcc by supplying the
"-fPIC" flag when compiling unshared (static) objects (a.k.a. ".a"
files). However, this is considered bad form by some, and in the
general case it's a total waste to do this because static objects don't
need symbol relocation information because they'll never be relocated.
5) You can't just pick up and build shared versions of these libraries
unless someone is willing to keep track of their sonames and increment
the versioning when an incompatible change is made to the library.
Otherwise, you stand an excellent change of rendering your users'
programs useless with unresolved symbol errors when they try to run
them.
6) However, you're still stuck on the architectures mentioned in 3) in
one case. While it's perfectly possible to ensure that various
tools provide different link flags depending on whether they're being
used to construct executables or libraries (Debian's solution was to
implement things like "sdl-config --library-libs" in addition to the
existing "sdl-config --libs" option), there is still the problem of
plugins that are dlopen()ed.
Real world example: there is a plugin for XMMS called "smpeg-xmms" that
uses the SMPEG library, which is based on SDL, to playblack MPEG movies.
Now, XMMS itself doesn't use SDL, or the aforementioned static X
extension libraries. Therefore it has no reason to contain these static
objects in its binary. (You can link them but they will just be
stripped away because they're not referenced by anything.) The smpeg
library, being based on SDL, though *does* need these symbols, and
expects them to be present in the execution environment. How is the
application writer who supports plugins to know what kind of symbols
might be needed by the objects he dlopens? He isn't. Part of the point
of writing plugin-aware apps is the freedom you give other people to
extend your tool. You can't pre-emptively link against every static
library in the world in an effort to meet their needs.
Under the current set of circumstances, users of the aforementioned
architectures are just up a creek when it comes to these plugins. One
solution, however, is to build two unshared forms of these static
extension libraries, e.g., libXxf86dga.a and libXxf86dga_pic.a. The
latter can and should be used *only* by shared objects that expect to be
dlopened. I poked around in Imake.rules and found rules that *might* do
something like this, but I have to admit I didn't understand what I read
enough to be sure.
Would it be possible to support this? Can a select few static libraries
be made available in _pic.a versions in a subsequent release? Does the
infrastructure for doing this presently exist in imake? Let me know
what I can do to realize this solution, or some other one that will meet
the same needs.
Also, if I've gotten any facts wrong in the above analysis, please
correct me.
--
G. Branden Robinson | I've made up my mind. Don't try to
Debian GNU/Linux | confuse me with the facts.
[EMAIL PROTECTED] | -- Indiana Senator Earl Landgrebe
http://people.debian.org/~branden/ |
PGP signature
