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
