[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-xwin-discuss
Subject:    Re: [xwin-discuss] [tools-linking] Splitting libXext.so.0
From:       Rod Evans <Rod.Evans () sun ! com>
Date:       2007-12-11 2:06:11
Message-ID: 475DF093.6000706 () sun ! com
[Download RAW message or body]

Alan Coopersmith wrote:
> 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?

It's not going to give the lazy loading you want.  -N just records
a dependency name, it doesn't seem to inherit the "lazy" attribute
(which could be argued to be a bug).  But, when you use -W, the compiler
driver takes all the associated arguments and prefixes them to the
ld(1) command line - so, they end up being read *before* the lazy flag.

Pretty unintuitive and confusing to have uses follow this.

> 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?

libX11 presently has a lazy dependency on libXext.so.0, but if the
old JDK/JRE have a dependency on this library, then this library
must be loaded before the JDK/JRE reference any symbols from it.

What if you make libXext.so.0 a filter for every symbol it presently
offers (like libXnet), and put the Sun specific stuff in a new Sun
specific library - libSUNWjunk.so.1 (or should that be
libJAVAjunk.so.1).  With this, libXext.so.0 can be built solely from
a mapfile first within you're build environment, then what ever needs
to can reference this filter as a dependency.  Make sure libX11
doesn't lazy load libXext.so.0, that way the old JDK/JRE references
will be satisfied by interposition.  You pay a small cost for
loading the libXext.so.0, but you don't trigger the loading of
any of its backing files unless a symbol reference binds to this
filter.

That's if I understand your issues correctly.


-- 
Rod
_______________________________________________
xwin-discuss mailing list
xwin-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]