This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
AW: SETUP WIZARD FOR CYGWIN?XFREE
- To: "Cygwin-Xfree" <cygwin-xfree at sources dot redhat dot com>
- Subject: AW: SETUP WIZARD FOR CYGWIN?XFREE
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- Date: Tue, 24 Jul 2001 15:57:29 +0200
>
> > Ralf Habacker wrote:
> >
> > > in some points I agree with you, I have added some necessary
> > libs like
> > > png,tiff,gif,zlib from a current cygwin distribution because for
> > preventing
> > > of version conflicts.
> >
> >
> > Ralf, why did you do this? We've already gone over this -- and,
> > given
> > the deference I have given the xfree team w.r.t. defending
> > Suhaib's
> > position on libfreetype, changing my xpm package which predated
> > the
> > xfree version, etc, I expect reciprocal respect from you guys.
> >
> > Why are you forking my cygwin packages?
>
> Ok now Ralf,
>
> You are going to cause a lot of confusions with providing different versions
> of XPM, libtif, libpng and libjpeg etc. I am 100% sure you can use the
> libraries from current distributions from Cygwin and Xfree86.
If you say that, I will try it, although I have had much trouble with the cygwin
dll
(socket problems) and my confidence is a little corrupted because of initial
ignoring
my cygwin bug report. Additional I have had trouble with ncurses lib which was
linked with
cygwin 1.3.1 and don't work with cygwin 1.1.8 because of using the
check_for_executable()
function.
This seem to me, that sometime patches are made and released which have some
unknown side affects. Don*t misunderstand me, I like cygwin very much, but whis
that
I see me running in great troubles.
At next the original kde package contains a gif6a lib which collidates with the
gif 6b
package of cygwin, so I decided to take the cygwin jpeg lib.
xfree for example depends only on cygwin, but kde (kfm.exe) depends from about
18 dll's.
The full dependency list (a part from cygcheck -v) contains 1481 lines.
.\kfm.exe
C:\programme\cygwin\usr\X11R6\bin\libX11.dll
C:\programme\cygwin\bin\cygwin1.dll
C:\WINNT\System32\KERNEL32.dll
C:\WINNT\System32\NTDLL.DLL
C:\programme\cygwin\usr\X11R6\bin\libXext.dll
.\cygkdecore-2.dll
C:\programme\cygwin\usr\src\redhat\SOURCES\kde\qt-1.45\bin\qt-1-44.dll
C:\programme\cygwin\usr\X11R6\bin\libX11.dll
C:\programme\cygwin\bin\cygwin1.dll
C:\WINNT\System32\KERNEL32.dll
C:\WINNT\System32\NTDLL.DLL
C:\programme\cygwin\usr\X11R6\bin\libXext.dll
.\cygkdeui-2.dll
.\cygkfile-2.dll
.\cygkfm-2.dll
.\cygkhtmlw-2.dll
.\cygjscript-2.dll
.\cygkimgio-2.dll
.\cygjpeg6b.dll
.\cygpng2.dll
.\cygz.dll
.\cygtiff3.dll
Can you image the problems, if only one external lib will not work correctly.
I remember the cygwin socket bug. I have spend one whole week with 5 hours a day
to identifiy that cygwin must be problem, to hear that usually the client code
has
the problem. So if I imaging, how much combination of problems could be, I see
me
supported kde 1.1.2 the whole day for the rest of my life.
For that, I thing it is a lesser problem to provide a beta release with some
minor
dlls which could be removed in every next beta release.
2) I have seen, that the xfree distribution contains a libz.dll too. Why don't
use
the cygwin dll "cygz.dll".
Which zlib I should use, from the cygwin or from the x11 release ??
Again, don*t misunderstand me not, I like cygwin and the xfree server
> create a big mess down the road, and I am pretty sure maintainers of Cygwin
> and Xfree86 will not like it. The best way of developing and supporting a
> package is to port your code to use the libraries from these packages
> (Cygwin and XFree86).
>
Nothing else I have done. I have installed cygwin and xfree and compiled kde.
The only
thing I have done is to put current cygz.dll, cygjpeg6b.dll, cygpng2.dll,
cygtiff3.dll and
a cygncurses5.dll linked with cygwin 1.1.8 to allow users using cygwin 1.1.8
into the
kdesupprt package. As /usr/local/kde1/bin is by default only added to PATH
inside kde,
this seems to be currently no problem.
Additional I have read about a "non-new-package" of cygwin, so distributing kde
directly
with cygwin isn*t possible at now. As I have to work on other projects in the
next time too,
so I have to release this beta now.
I hope you understand a little bit more of my prudence. I like to say, I have no
problem
to work together with the cygin and cygwin-xfree guys, so i think we find a good
way to deal
with that all.
Ralf
> Suhaib
>
>
> >
> > If you are worried about version conflicts, there is no need. Now
> > that
> > the early growing pains with dlls (the infamous dll-naming thread
> > on
> > cygwin-apps, the libfoo.dll to cygfoo.dll transition, the .dll.a
> > convention) are behind us, the only time dll names in the main
> > distribution will change is when the ABI/API changes -- which
> > would
> > require relink/recompile anyway.
> >
> > AND in those cases, the old DLLs will continue to be supplied --
> > take a
> > look inside the current readline-4.2 binary tarball. You'll see
> > /usr/bin/cygreadline4.dll (from the 4.1 dist) AND
> > /usr/bin/cygreadline5.dll (from the 4.2 dist). You'll see
> > /usr/lib/libreadline.dll.a which is the import lib for
> > cygreadline5, so
> > that all new progs will use the new dll. BUT, older progs will
> > continue
> > to work because the old dll is THERE.
> >
> > There is no need to distribute copies yourself -- and in fact,
> > that is
> > harmful. Please don't do it. Did you even read this message?
> >
> > ----------------------
> > Re: AW: ask for delivering cygwin 1.1.8 with kde 1.1.2
> >
> > http://www.cygwin.com/ml/cygwin-apps/2001-06/msg00057.html
> >
> >
> > I think we're slowly converging on a system in which:
> > when a library is updated so that the new dll is not backwards
> > compatible (that is, the DLL name changes to represent an ABI/API
> > incompatibility), then we try to insure continued operation for a
> > reasonable time. "reasonable" is open to interpretation.
> >
> > There are two ways to do this:
> >
> > 1) the new package contains the headers, import libs, DLL's and
> > static
> > libs for the NEW library, AND contains the old DLL's. This is
> > what we
> > chose to do with readline.
> >
> > 2) or the incompatible library is released with a different
> > package
> > name. However, since in all likelihood, the new package will
> > contain
> > files that conflict with the old package, the old package should
> > be
> > simultaneously updated to a new *version*, that contains only the
> > DLL's
> > -- since the names are different, those won't conflict with the
> > DLL's in
> > the new package.
> >
> > In effect, both options are the same. 1) is simpler, and easier
> > for us
> > volunteer maintainers. 2) makes it optional whether the use wants
> > to
> > download a bunch of (useless?) old dll's, and is more in line with
> > the
> > way most linux distributions handle it.
> > ----------------------
> >
> > Now, I realize there are reasons for the cygwin1.dll-1.1.8 thing
> > and the
> > cygwin1.dll-post-1.3.2-snapshot thing. That's different. I'm
> > complaining about the duplicate distribution of stable dll's.
> > Just as
> > Suhaib was justified in complaining about Xpm.dll, I feel
> > justified in
> > this.
> >
> > Of course, it's all GPL -- I can't stop you. But I really believe
> > that
> > duplicate distribution will only cause trouble down the road.
> >
> > Unless, of course, you want to volunteer to take over
> > maintainership of
> > those packages (zlib, libpng, libtiff, libjpeg, libjbig). That
> > too is a
> > possibility -- I am looking for somebody to take over...
> >
> > --Chuck
>