This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: XFree 4.2.1 + fontconfig-2


--- Alexander Gottwald <Alexander.Gottwald@informatik.tu-chemnitz.de>
wrote:
> Alan Hourihane wrote:
> 
> > On Wed, Sep 18, 2002 at 10:25:48 +0200, Alexander Gottwald wrote:
> > > That is a windows problem. The XFree libraries are in fact
> versioned.
> > > (libXaw.so.6.1 vs libXaw.so.7.0)
> > 
> > Alexander,
> > 
> > You've hit a sore spot here. The issue of Xft1 vs Xft2 was only
> the
> > starting of a larger picture.
> > 
> > Your right in the fact that all libraries are versioned, and we
> don't
> > respect that for any library. libX11.a should really be
> libX11-6_2.a etc
> > or some equivalent of.
> 
> The .a libraries should not be the big problem. You usally have one
> version
> of it installed (with the corresponding headers). But the shared
> libraries
> might be a problem.

Only if things are not properly coordinated.  All that has to be done
is to rebuild the entire XFree base stuff.  Then give it to the
package maintainers who depend on X11 a few weeks before a given
release time.  That should give them sufficient time to relink their
packages and prepare a micro-version bump [r(n)->r(n+1)].  Then
release all the updated packages at once.  That way, there's no
"lagging" in the core distribution.  The 3rd party people will have
to catch up, but we can let them know as well (Ralf, Steve, etc.). 
Still, maybe it might be worth waiting until 4.3.0 is released?

> Taking a look at my linux system and libXaw. 
> I've installed libXaw.so.6.1 and libXaw.so.7.0 and libXaw.so as a
> symlink
> to libXaw.so.7.0
> 
> Linking a library with libXaw.so creates a binary which expects at
> least
> libXaw.so.7.0 but is incompatible with libXaw.so.6.*
> 
> A binary linked against libXaw.so.6.1 requires at least
> libXaw.so.6.1 and is
> incompatible with libXaw.7.* and might not work with libXaw.so.6.0.
> 
> Mapping this the windows we get a scenario where we have on program
> against
> libXaw7.dll and one against libXaw6.dll but with no information on
> minor 
> version changes. And maybe another libXaw.dll which works as
> library stub
> when linking with -lXaw

Sure, you can add more information if you want to.  libXaw.6.0.dll.a
as an import lib for cygXaw-6.0.dll is perfectly valid and will
happily coexist with cygXaw-6.1.dll :).  All that's required is to
symlink the base import library (libXaw.dll.a) to whichever is
determined to be the default.

> The ncurses4 vs. ncurses5 issue shows a lot of the problems which
> will
> arise. 

This is true, but Chuck also showed us the best way to handle it. 
Yeah it looked like a pain, but it could have been worse without
proper planning.

> Every new program which is linked against libXaw7 will not work
> with libXaw.dll and older programs will still search for libXaw.dll

> which is now ibXaw6.dll.
> 
> quite tricky.

Not if we just accept the fact that there is no workaround and focus
on "damage" control.  That is, make sure people are informed well in
advance and the X11 maintainers have time to get their releases
relinked.  The fallout from ncurses wasn't that bad, the volume died
off a few weeks after it happened.
 
> Any other solutions or comments?

The only other way is to leave things as they are, but this will need
to be done eventually, right?

Cheers,
Nicholas

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]