RFU: pngcrush-1.7.26
New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.26+20120223+gitb6d8931-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.26+20120223+gitb6d8931-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngcrush/setup.hint Jari
RFU: optipng 0.6.4-1 (libpng14)
New upstream release, compiled against libpng14 wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/optipng/optipng-0.6.4-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/optipng/optipng-0.6.4-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/optipng/setup.hint Jari
RFU: pngquant 1.7.2-1
New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pngquant/pngquant-1.7.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngquant/pngquant-1.7.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngquant/setup.hint Jari
RM: spamprobe
Please remove spamprobe: - No longer compiles with latest libdb - Blocks libpng12 to libpng14 upgrade on Cygwin - There are alternatives Jari
ORPHAN: fvwm
I'm orphaning fvwm: - Builds OOTB without any patches - However upgrading to latest version from currect one in Cygwin is a leap; all Xorg libraries etc. have changed. - libpng14 transition seems to work (builds ok) In case someone want's to take over, here is the latest I had on my disk [*]: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/fvwm/fvwm-2.6.3-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/fvwm/fvwm-2.6.3-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/fvwm/setup.hint I've done no testing on that one. Refer to fvwm.README in the package for current upstream informatiom. Jari [*] Couldn't access project's homepage to see if there is any later version.
RFU: wcd 5.2.1-1
New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/wcd/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.1-1.tar.bz2 Jari
Re: Mingw64 and Cygwin: header and libs layout
On Mar 24 22:59, Dave Korn wrote:
> On 24/03/2012 19:19, Corinna Vinschen wrote:
> > On Mar 24 18:12, Dave Korn wrote:
> >> On 13/03/2012 10:10, Corinna Vinschen wrote:
> >>
> >>> For the time being, I'm using the -idirafter flag to include the Mingw64
> >>> headers into the search path, but that's IMHO not a generic solution for
> >>> a (yet to create) Cygwin 64 bit GCC.
> >> The generic solution for the future cygwin64-targeted GCC will of course
> >> be
> >> to not refer to the mingw64 headers at all!
> >
> > Huh?
>
> Just like the current i686-pc-cygwin-gcc does not refer to mingw32 headers,
It does.
$ gcc -dumpspecs | grep w32api
%(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{mno-win32:%{mno-cygwin: %emno-cygwin
and mno-win32 are not compatible}} %{mno-cygwin:-D__MSVCRT__ -D__MINGW32__
%{!ansi:%{mthreads:-D_MT}}} %{!mno-cygwin:-D__CYGWIN32__ -D__CYGWIN__
%{!ansi:-Dunix} -D__unix__ -D__unix } %{mwin32|mno-cygwin:-DWIN32 -D_WIN32
-D__WIN32 -D__WIN32__ %{!ansi:-DWINNT}}
%{!nostdinc:%{!mno-win32|mno-cygwin:-idirafter ../include/w32api%s -idirafter
../../include/w32api%s}}
> a future theoretical x86_86-pc-cygwin64-gcc will not refer to mingw64 headers,
> because we'll have a proper native compiler rather than having to rely on a
> cross-compiler that is almost - but not quite - correct.
>
> > Sorry, but I don't understand what you mean. Of course we would like
> > to share headers *and* libs. See above.
>
> OK, then I clearly don't understand what you mean. Didn't this thread start
> with you pointing out that, although the same headers were valid for cygwin or
> mingw, the startup crt .o files and libs weren't right? How can the cygwin .o
> files possibly be compatible with the mingw ones?
Uh, that's a misconception. I was talking about the platform headers and
libs, not the Mingw64 CRT headers and libs. The platform headers and libs
are what is known as w32api so far. What I'm talking about all the time
is *only* the platform part. The mingw64 specific headers and libs should
stay were they are today, in the /usr/{$target}-w64-mingw32/ subdirs.
Does that make things clearer now? I'm a bit puzzeled because
throughout this thread we're refering to w32api subdirs or symlinks, not
mingw32 subdirs or symlinks. Of course we have no reason to use
Mingw{32,64} CRT headers and libs.
OTOH we *must* have access to the w32api libs, because we can't generate
running apps without linking at least against kernel32 (for crtbegin.o).
> > The include files are the
> > same for 32 and 64 bit, while the libs are obviously different.
>
> So why do you want to share the libs, since they are different?
See above.
> > Therefore
> > it makes sense to create a shared directory which contains the shared
> > include
> > files as well as the different libs for the different platforms.
>
> Ah, well, not to me it doesn't. To me, what makes sense is
> (headers+libs)*different.platforms, not (headers)*different.platforms +
> (libs)*different.platforms, and this is what the entire GNU/Linux/Unix $prefix
> structure assumes.
Again, this is only about shareing the plaform stuff. If we keep
/usr/include/w32api, /usr/lib/w32api, and /usr/lib64/w32api as symlinks,
does it really matter where the files actually are?
> I think this is a little bit like big-endian vs.
> little-endian arguments: should the library itself be the most significant
> part, or the target? Regardless the arguments one way or another, the GNU
> system has already adopted the decision that $target is the most-significant
> part of a $prefix layout.
>
> > My idea is to keep the w32api "subdirs" under /usr/include and /usr/lib,
> > and add a new one under /usr/lib64. These could be implemented as real
> > subdirs, or as symlinks to, for instance,
> > /usr/share/windows_psdk/{include,lib,lib64}, as outlined above.
> >
> > The question is just where to keep the actual include and lib files in
> > this scenario, and Kai's suggestion was to keep them under
> > /usr/share/windows_psdk.
>
> What you're implying there, is that from now forever onward, the cygwin
> w32api and cross-mingw-w32api packages always have to be kept in perfect
> lock-step, if there's only going to be one set of headers for two sets of
> libs. That seems like a potential source of incompatibilities to me; as I was
> trying to suggest in my comment about autoconfig-customised variants of the
> headers, it may one day be the case that the headers for one set of libs have
> to actually say something different from the headers for the other set of
> libs, and we're tying our own hands in advance if we decide that one common
> set of headers has to serve the same lib for two separate targets.
And why should this be done? It doesn't look as if Microsoft will ever
generate autoconf'ed, target-specific headers in different directories
and Mingw64 strives to create platform headers in as most compatible as
possible. Kai, what do you say
And then, if w
Re: Absent maintainers
On Mar 24 20:46, Dave & Diane wrote: > I'm still monitoring Cygwin, it's just so good I don't need to say anything > ;-) > > Unfortunately Lucent have taken down the public mlcscope, so there will be no > updates to it. There hasn't been any activity around it on the Cygwin mailing > lists that I've seen. If I've missed something, I need to fix my filters... Ok, thanks for your reply. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RFU (test): libfltk-1.3
LS, following heads-up of Yaakov http://sourceware.org/ml/cygwin/2012-03/msg00518.html please upload following as test package, wget -x -nH --cut-dirs=2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-1.3-1-src.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-1.3-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-devel/libfltk-devel-1.3-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-devel/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-doc/libfltk-doc-1.3-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-doc/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/setup.hint Kind regards, Teun
Re: RFU (test): libfltk-1.3
On 2012-03-25 13:54, A.R. Burgers wrote: please upload following as test package, http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-1.3-1.tar.bz2 This subpackage should be libfltk1.3, just as the 1.1 DLLs are in libfltk1.1. Yaakov
Re: RM: spamprobe
On Sun, Mar 25, 2012 at 01:19:09PM +0300, Jari Aalto wrote: >Please remove spamprobe: > >- No longer compiles with latest libdb >- Blocks libpng12 to libpng14 upgrade on Cygwin >- There are alternatives I created an empty package and moved the category to "_obsolete".
Re: RFU: optipng 0.6.4-1 (libpng14)
On 2012-03-25 04:35, Jari Aalto wrote: New upstream release, compiled against libpng14 wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/optipng/optipng-0.6.4-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/optipng/optipng-0.6.4-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/optipng/setup.hint Uploaded with one correction: requires: libpng14 zlib0 (not `zlib') Please be sure to fix your local copy. Yaakov
Re: RFU: pngcrush-1.7.26
On 2012-03-25 03:29, Jari Aalto wrote: New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.26+20120223+gitb6d8931-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngcrush/pngcrush-1.7.26+20120223+gitb6d8931-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngcrush/setup.hint Uploaded. Can any previous versions be removed? Yaakov
Re: RFU: pngquant 1.7.2-1
On 2012-03-25 04:58, Jari Aalto wrote: New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pngquant/pngquant-1.7.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngquant/pngquant-1.7.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pngquant/setup.hint Uploaded. Can any previous versions be removed? Yaakov
Re: RFU: wcd 5.2.1-1
On 2012-03-25 06:24, Jari Aalto wrote: New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/wcd/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.1-1.tar.bz2 Uploaded. Can any previous versions be removed? Yaakov
[ITA] fvwm
I think people still use this, so: ftp://ftp.cygwinports.org/pub/cygwinports/uploads/fvwm/ Yaakov
Re: RFU (test): libfltk-1.3
On 2012-03-25 13:54, A.R. Burgers wrote: please upload following as test package, wget -x -nH --cut-dirs=2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-1.3-1-src.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-1.3-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-devel/libfltk-devel-1.3-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-devel/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-doc/libfltk-doc-1.3-1.tar.bz2 \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/libfltk-doc/setup.hint \ http://members.quicknet.nl/ar.burgers/cygwin17/libfltk/setup.hint Besides versioning the DLL subpackage, there are more problems with this package: * Please use "fltk" for PN instead of libfltk as you did for 1.1. * PV is vague. Either it should be 1.3.0 for the stable version or e.g. 1.3.0.9296 for the latest 1.3.x snapshot. * The -devel and -doc packages are reversed; replace the PKG_* lines with: PKG_NAMES="libfltk1.3 libfltk-devel libfltk-doc" libfltk1_3_CONTENTS="usr/bin/*-1.3.dll" libfltk_devel_CONTENTS="--exclude=doc etc/ usr/bin/fltk-config usr/bin/fluid.exe usr/include usr/lib/ usr/share/" libfltk_doc_CONTENTS="usr/share/doc/" * Please install libXinerama-devel when rebuilding, which will add a dependency on libXinerama1. Thanks, Yaakov
