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]

AW: SETUP WIZARD FOR CYGWIN?XFREE


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


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