Over the years, the Solaris libXext.so.0 has accumulated functions
for a bunch of extensions that aren't in X.Org's libXext (which on
most other platforms ships as libXext.so.6). A number of these
were put into separate libraries by X.Org, others are Sun specific.
As we transition to building from the X.Org sources, it seems the
cleanest way to resolve this is to make libXext.so.0 a binary
compatibility library and ship the X.Org libXext.so.6 and associated
libraries instead.
To avoid code duplication, conflicts or breaking compatibility, the
libraries would be built as such:
- libXss.so.1, libXevie.so.1 & libXinerama.so.1 - current X.Org
sources, containing functions Solaris has in libXext.so.0
- libXext.so.6 - the current X.Org sources, a subset of libXext.so.0
- libXext.so.0 - the remaining sources from the current libXext
that aren't in any of the above, built with a mapfile listing
filter entries pointing to libXext.so.6, libXss.so.1, libXevie.so.1
& libXinerama.so.1 for those functions now found in those
- libXext.so would point to libXext.so.6
Unfortunately, because life is never that simple, Solaris libX11
links against libXext.so.0, even though that's a circular dependency,
and as I found out the hard way, removing this dependency breaks
old versions of the JDK/JRE which were incorrectly linked against
only libX11 despite using libXext functions. To preserve this,
libX11 would be built with the compiler/linker magic flag
-Wl,-N,libXext.so.0 to keep this dependency around, though hopefully
rarely triggered (since libX11 is built -zlazyload).
Should this work? Is this a good idea? Is requiring the few
people out there who use the Sun-specific extensions to use the
-Wl,-N,libXext.so.0 going to be a problem?
Would it be better if libXext.so.0 became nothing but filters to the
other 4 libraries and the Sun-specific functions moved to the new
libXext.so.6?
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
