[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: SDL and X static extension libraries re-revisited



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


Reply to: