Hi folks, There is still one more issue to tackle with SDL vis a vis the static X extension libraries that it uses. Fortunately, this one will be far less disruptive than the last, and will not affect library interfaces in any way. A quick recap: 1) In XFree86 4.1.0, the extension libraries 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 a violation of Debian Policy, 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 (We have already implemented "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 have prepared experimental XFree86 packages that implement the X side of the solution to the above problem. Surf to the X Strike Force (see the URL in my .sig) and retrieve the "xlibs-pic" package. WHAT OTHER PACKAGES NEED TO DO: 1) The existing SDL and related libraries need to be modified again in a manner similar to my patch that implemented "--library-libs". We need another new option to sdl-config and friends to indicate linkage for plugins. I suggest "--plugin-libs". Thus, we'll have 3 different ways of asking sdl-config for linkage information: (For standalone apps) sdl-config --libs -L/usr/lib -lSDL -lpthread -L/usr/X11R6/lib -lXxf86dga -lXxf86vm -lXv (For ordinary shared libraries) sdl-config --library-libs -L/usr/lib -lSDL -lpthread (For dlopenable plugins) sdl --plugin-libs -L/usr/lib -lSDL -lpthread -L/usr/X11R6/lib -lXxf86dga_pic -lXxf86vm_pic -lXv_pic Some or all of the following packages will be affected by this change. libsdl1.2 sdl-image1.2 sdl-mixer1.2 sdl-net1.2 sdl-ttf1.2 smpeg gengameng I have no reason to believe that any other packages will be affected in this step. And non-plugin-based packages that use SDL should not be affected at all. They will not require a rebuild or any other changes. 2) Packages that contain SDL-based plugins need to be modified to call, for example, "sdl-config --plugin-libs" instead of "sdl-config --libs". They will also have to Build-Depend on xlibs-pic, and versions of the SDL/smpeg/etc. libraries that implement the change in 1) above. Note that the dependencies of the binary package will not be affected. Fortunately, only 4 or 5 source packages are affected by this: noatun-plugins smpeg-xmms vlc-sdl xmps-common (xmms-goom might also be affected, but I haven't looked closely at it.) I am not yet planning any NMU's. I am waiting to hear back from XFree86 upstream to ensure that they won't be upset by my changes to XFree86 to implement this _pic.a support. (I don't anticipate that they will be.) Also, I'd like to gather feedback from the affected package maintainers. Comments? -- G. Branden Robinson | The greatest productive force is Debian GNU/Linux | human selfishness. branden@debian.org | -- Robert Heinlein http://people.debian.org/~branden/ |
Attachment:
pgpvl4hkyo8MY.pgp
Description: PGP signature