Re: [ITA] w32api-3.0b_svn5368-1
On Aug 13 21:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? It doesn't hurt to have the 64 bit libs already available, does it? It allows to install a cross gcc for x86_64-pc-cygwin at one point and the w32api headers are already available? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:18, Corinna Vinschen wrote: On Aug 13 21:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? I had to look it up: Fails To Build From Source. /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’ windef.h:23: typedef unsigned __LONG32 ULONG; It doesn't like the __LONG32. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Corinna
Fixed at rev. 5371. The include should come before the 'extern C {' clause.
Thanks for reporting. It might be that there are some of those issues
remaining caused by the LP64 support-changes.
Regards,
Kai
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:34, Corinna Vinschen wrote:
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
Andy
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 08:46, Andy Koppe wrote:
On 14 August 2012 08:34, Corinna Vinschen wrote:
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
I think this is because the mingw-w64 libs come with a couple more
static elements built into the libs (GUIDs and stuff).
Kai, can you explain the difference?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai
Re: [ITA] w32api-3.0b_svn5368-1
On 8/14/2012 10:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. It contains the headers and win32 and win64 DLL import libraries. It does require multilib capable GCC to build. Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? Like Corinna says, 64bit Cygwin has to start somewhere. Yaakov: Can cygport implement a new inherit where it is similar to cross, except it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get around it. To bootstrap, you could just unset CC/CXX and configure with --host=x86_64-w64-mingw32. But once the new w32api is installed, if you configure with --disable-lib64, this should be buildable with Cygwin's native GCC. I did not think of that, thanks. signature.asc Description: OpenPGP digital signature
Re: [SECURITY] tiff, libpng
Chuck? Ping 2? If you don't reply I guess we have to assume you're not with us anymore. Which would be too bad. On Aug 3 09:58, Corinna Vinschen wrote: Chuck? Ping? Are you still with us? On Jul 23 16:48, Yaakov (Cygwin/X) wrote: Chuck, Security vulnerabilities are accumulating for the tiff package (CVE-2011-0192, CVE-2011-1167, CVE-2012-1173, CVE-2012-2088, CVE-2012-2113, CVE-2012-3401). This can be fixed by updating to 3.9.6 and applying the four patches found here: http://pkgs.fedoraproject.org/gitweb/?p=libtiff.git;a=tree;h=refs/heads/f17;hb=f17 There are also security vulnerabilities in the libpng packages (CVE-2011-3026, CVE-2011-3048, and now CVE-2012-3386). These need to be updated to the latest 1.4.12, 1.2.50, and 1.0.60 releases. PLEASE update these packages ASAP. Yaakov Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [SECURITY] exif
Jari? Ping? On Jul 26 23:13, Yaakov (Cygwin/X) wrote: Jari, A security vulnerability (CVE-2012-2845) has been announced for the outdated version of the exif package currently in the distribution. Please update exif to 0.6.21 ASAP. And while I'm at it, ping: http://cygwin.com/ml/cygwin-apps/2008-11/msg00078.html http://cygwin.com/ml/cygwin/2012-04/msg4.html http://cygwin.com/ml/cygwin/2012-04/msg5.html Yaakov Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[SECURITY] emacs
Ken, A security vulnerability has been announced for GNU Emacs, details and patches for 23.4 and 24.1 here: https://bugzilla.redhat.com/show_bug.cgi?id=847698 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f16 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f17 TIA, Yaakov
Re: [SECURITY] tiff, libpng, automake
On Tue, 2012-08-14 at 22:05 +0200, Corinna Vinschen wrote: Chuck? Ping 2? If you don't reply I guess we have to assume you're not with us anymore. Which would be too bad. Indeed. :-( On Aug 3 09:58, Corinna Vinschen wrote: On Jul 23 16:48, Yaakov (Cygwin/X) wrote: Chuck, Security vulnerabilities are accumulating for the tiff package (CVE-2011-0192, CVE-2011-1167, CVE-2012-1173, CVE-2012-2088, CVE-2012-2113, CVE-2012-3401). This can be fixed by updating to 3.9.6 and applying the four patches found here: http://pkgs.fedoraproject.org/gitweb/?p=libtiff.git;a=tree;h=refs/heads/f17;hb=f17 There are also security vulnerabilities in the libpng packages (CVE-2011-3026, CVE-2011-3048, and now CVE-2012-3386). These need to be updated to the latest 1.4.12, 1.2.50, and 1.0.60 releases. And now there's YA: automake1.11 needs a bump to 1.11.6 for CVE-2012-3386; earlier branches are also affected, but I haven't seen any backporting patches yet. Yaakov
Re: [SECURITY] emacs
On 8/14/2012 8:17 PM, Yaakov (Cygwin/X) wrote: Ken, A security vulnerability has been announced for GNU Emacs, details and patches for 23.4 and 24.1 here: https://bugzilla.redhat.com/show_bug.cgi?id=847698 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f16 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f17 Thanks. This is being discussed on the emacs-devel list, and emacs-24.2 is going to be released within a few days, with a fix. I'll patch emacs-23.4 at the same time. Ken
Re: [SECURITY] lighttpd
On Thu, 2012-03-29 at 13:39 -0500, Yaakov (Cygwin/X) wrote: On 2012-03-29 09:58, Lapo Luchini wrote: Yaakov (Cygwin/X) wrote: BLODA? Not that I know of: WindowsDefender is deactivated (and I checked the service is not running), and only other stuff in the BLODA is nVidia, some version but I can't really do much to avoid that. I wonder. So do I, because: configure.ac:57: error: possibly undefined macro: AC_CHECK_HEADERS configure.ac:71: error: possibly undefined macro: AC_DEFINE configure.ac:108: error: possibly undefined macro: AC_CHECK_LIB configure.ac:112: error: possibly undefined macro: AC_MSG_ERROR autoreconf-2.68: /usr/bin/autoconf-2.68 failed with exit status: 1 *** ERROR: autoreconf failed Then something is wrong with your installation or environment. I'll need your `cygcheck -srv' output. Same goes for a fresh install on real hardware (Win7 box in my office). Nothing obvious in the cygcheck. But as these macros are part of autoconf itself, if autoconf can't find them, it means that aclocal silently failed. In any case, this is an issue with your system (probably BLODA or rebase), not with cygport. Ping? lighttpd 1.4.31 is available now. Yaakov
Re: XWin.exe segmentation fault on Windows 7
On Aug 14 16:41, Chris LeBlanc wrote: Now the question is, if the same problem occurs, why? Please paste the contents of /etc/fstab and, if it exists, /etc/fstab.d/$USER into your reply. Thanks for the information, I think we're getting closer to finding the problem. /etc/fstab doesn't have anything in it apart from comments, and the /etc/fstab.d directory is empty. Here is the output from the mount command: C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto) Segmentation fault (core dumped) It fails when it reaches a network share. Looking at them in Windows Explorer, they're all NcFsd network shares ... That was the essential information to find the bug. For the last Cygwin version I added support for the new ReFS filesystem and I changed one datastructure without also changing another, closely related datastructure. The bug would have shown for other FSes as well, but it would only have resulted in printing the wrong FS type in mount. Only for NcFsd it was bound to crash. This will be fixed in the (soon to come) Cygwin 1.7.17. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog errno.cc mount.cc ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-08-14 09:54:31 Modified files: winsup/cygwin : ChangeLog errno.cc mount.cc mount.h Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.3r2=1.5939.2.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/errno.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.87r2=1.87.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.93r2=1.93.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.24r2=1.24.2.1
src/winsup/cygwin ChangeLog mkvers.sh
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-08-14 11:13:12 Modified files: winsup/cygwin : ChangeLog mkvers.sh Log message: * mkvers.sh: Drop reference to w32api includes. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.4r2=1.5939.2.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mkvers.sh.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.21r2=1.21.2.1
winsup/cygwin ChangeLog errno.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2012-08-14 14:56:19 Modified files: cygwin : ChangeLog errno.cc Log message: * errno.cc (errmap): Keep sorted. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5941r2=1.5942 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/errno.cc.diff?cvsroot=uberbaumr1=1.88r2=1.89
src/winsup/cygwin ChangeLog thread.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-08-14 15:05:14 Modified files: winsup/cygwin : ChangeLog thread.cc Log message: * thread.cc (semaphore::_fixup_after_fork): Fix Win32 error output in api_fatal call. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5942r2=1.5943 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.270r2=1.271
src/winsup/cygwin ChangeLog errno.cc thread.cc
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-08-14 17:16:56 Modified files: winsup/cygwin : ChangeLog errno.cc thread.cc Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.5r2=1.5939.2.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/errno.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.87.2.1r2=1.87.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.270r2=1.270.2.1
src/winsup/cygwin/config/x86_64
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-08-14 17:26:40 src/winsup/cygwin/config/x86_64 Update of /cvs/src/src/winsup/cygwin/config/x86_64 In directory sourceware.org:/tmp/cvs-serv29624/config/x86_64 Log Message: Directory /cvs/src/src/winsup/cygwin/config/x86_64 added to the repository -- Using per-directory sticky tag `cygwin-64bit-branch'
src/winsup/cygwin ChangeLog configure configur ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-08-14 17:27:24 Modified files: winsup/cygwin : ChangeLog configure configure.in Added files: winsup/cygwin/config/x86_64: profile.h Log message: * configure.in: Add AC_NO_EXECUTABLES to allow bootstrap. Add x86_64 to allowed cpu types. * configure: Regenerate. * config/x86_64/profile.h: New file. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.6r2=1.5939.2.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/configure.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.35r2=1.35.6.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/configure.in.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.38r2=1.38.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/config/x86_64/profile.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=NONEr2=1.1.2.1
winsup/cygwin ChangeLog errno.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2012-08-14 18:38:22 Modified files: cygwin : ChangeLog errno.cc Log message: * errno.cc (errmap): Keep sorted. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5943r2=1.5944 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/errno.cc.diff?cvsroot=uberbaumr1=1.89r2=1.90
src/winsup/cygserver ChangeLog configure confi ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-08-14 19:22:15 Modified files: winsup/cygserver: ChangeLog configure configure.in Log message: * configure.in: Add AC_NO_EXECUTABLES to allow bootstrap. * configure: Regenerate. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.85r2=1.85.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/configure.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5r2=1.5.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/configure.in.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5r2=1.5.2.1
src/winsup/cygwin ChangeLog advapi32.cc ntdll. ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2012-08-14 19:29:32 Modified files: winsup/cygwin : ChangeLog advapi32.cc ntdll.h thread.cc thread.h Log message: * advapi32.cc (DuplicateTokenEx): Make ?: expression type-safe. * ntdll.h (KAFFINITY): Don't define if building with Mingw64 headers. * thread.cc: Throughout drop casts in calls to Interlocked functions. * thread.h (class fast_mutex): Ditto. Define lock_counter as LONG. (class pthread_mutex): Define lock_counter as LONG. (struct MTinterface): Define threadcount as LONG. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.7r2=1.5939.2.8 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/advapi32.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.12r2=1.12.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ntdll.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.141r2=1.141.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.270.2.1r2=1.270.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.131r2=1.131.2.1
src/winsup/cygwin ChangeLog gmon.c
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2012-08-14 19:38:45 Modified files: winsup/cygwin : ChangeLog gmon.c Log message: * gmon.c (_mcleanup): Fix scope bug when using gmon_out array. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5944r2=1.5945 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/gmon.c.diff?cvsroot=srcr1=1.7r2=1.8
/dev/clipboard pasting with small read() buffer
--- sav/fhandler_clipboard.cc 2012-07-08 02:36:47.0 +0200
+++ ./fhandler_clipboard.cc 2012-08-14 18:25:14.903255600 +0200
@@ -222,6 +222,7 @@ fhandler_dev_clipboard::read (void *ptr,
UINT formatlist[2];
int format;
LPVOID cb_data;
+ int rach;
if (!OpenClipboard (NULL))
{
@@ -243,12 +244,18 @@ fhandler_dev_clipboard::read (void *ptr,
cygcb_t *clipbuf = (cygcb_t *) cb_data;
if (pos clipbuf-len)
- {
+ {
ret = ((len (clipbuf-len - pos)) ? (clipbuf-len - pos) : len);
memcpy (ptr, clipbuf-data + pos , ret);
pos += ret;
}
}
+ else if ((rach = get_readahead ()) = 0)
+{
+ /* Deliver from read-ahead buffer. */
+ * (char *) ptr = rach;
+ ret = 1;
+}
else
{
wchar_t *buf = (wchar_t *) cb_data;
@@ -256,25 +263,46 @@ fhandler_dev_clipboard::read (void *ptr,
size_t glen = GlobalSize (hglb) / sizeof (WCHAR) - 1;
if (pos glen)
{
+ /* If caller's buffer is too small to hold at least one
+max-size character, redirect algorithm to local
+read-ahead buffer, finally fill class read-ahead buffer
+with result and feed caller from there. */
+ char * _ptr = (char *) ptr;
+ size_t _len = len;
+ char cprabuf [8 + 1]; /* need this length for surrogates */
+ if (len 8)
+ {
+ _ptr = cprabuf;
+ _len = 8;
+ }
+
/* Comparing apples and oranges here, but the below loop could become
extremly slow otherwise. We rather return a few bytes less than
possible instead of being even more slow than usual... */
- if (glen pos + len)
- glen = pos + len;
+ if (glen pos + _len)
+ glen = pos + _len;
/* This loop is necessary because the number of bytes returned by
sys_wcstombs does not indicate the number of wide chars used for
it, so we could potentially drop wide chars. */
while ((ret = sys_wcstombs (NULL, 0, buf + pos, glen - pos))
!= (size_t) -1
- ret len)
+ ret _len)
--glen;
if (ret == (size_t) -1)
ret = 0;
else
{
- ret = sys_wcstombs ((char *) ptr, (size_t) -1,
+ ret = sys_wcstombs ((char *) _ptr, (size_t) -1,
buf + pos, glen - pos);
pos = glen;
+ /* If using read-ahead buffer, copy to class read-ahead buffer
+and deliver first byte. */
+ if (_ptr == cprabuf)
+ {
+ puts_readahead (cprabuf, ret);
+ * (char *) ptr = get_readahead ();
+ ret = 1;
+ }
}
}
}
2012-08-14 Thomas Wolff t...@towo.net
* fhandler_clipboard.cc (fhandler_dev_clipboard::read): Use
read-ahead buffer for reading Windows clipboard if caller's
buffer is too small for complete characters.
Re: New modes for cygpath that terminate path with null byte, nothing
Hi Corinna, On 7/27/2012 2:32 AM, Corinna Vinschen wrote: There's just the problem of the copyright assignment. If you want to provide a non-obvious patch, or if the patch adds new functionality, we need a copyright assignment from you. Please see the section Before you get started on http://cygwin.com/contrib.html and the assignment form http://cygwin.com/assign.txt As soon as my manager has the assignment, I'll apply your patch. Do you guys still want the patch (and papers that go with it)? If so, could I discuss the particulars of the assignment off-list somewhere? Thanks, Daniel Colascione signature.asc Description: OpenPGP digital signature
Re: New modes for cygpath that terminate path with null byte, nothing
On Tue, Aug 14, 2012 at 02:49:17PM -0700, Daniel Colascione wrote: On 7/27/2012 2:32 AM, Corinna Vinschen wrote: There's just the problem of the copyright assignment. If you want to provide a non-obvious patch, or if the patch adds new functionality, we need a copyright assignment from you. Please see the section Before you get started on http://cygwin.com/contrib.html and the assignment form http://cygwin.com/assign.txt As soon as my manager has the assignment, I'll apply your patch. Do you guys still want the patch (and papers that go with it)? If so, could I discuss the particulars of the assignment off-list somewhere? As I mentioned, it seems like you can easily get the functionality you're looking for by using standard Cygwin tools so, IMO, we don't need your patch. cgf
Re: New modes for cygpath that terminate path with null byte, nothing
On 8/14/12 10:02 PM, Christopher Faylor wrote: On Tue, Aug 14, 2012 at 02:49:17PM -0700, Daniel Colascione wrote: On 7/27/2012 2:32 AM, Corinna Vinschen wrote: There's just the problem of the copyright assignment. If you want to provide a non-obvious patch, or if the patch adds new functionality, we need a copyright assignment from you. Please see the section Before you get started on http://cygwin.com/contrib.html and the assignment form http://cygwin.com/assign.txt As soon as my manager has the assignment, I'll apply your patch. Do you guys still want the patch (and papers that go with it)? If so, could I discuss the particulars of the assignment off-list somewhere? As I mentioned, it seems like you can easily get the functionality you're looking for by using standard Cygwin tools so, IMO, we don't need your patch. I didn't know what the final decision was; that's why I asked. Corinna said she wanted the patch. As for the feature itself: piping through tr is fine, but having cygpath output paths in the desired way in the first place keeps error information around (without pipefail, $? is tr's exit status) and involves fewer forks. There's precedent in echo -n too. signature.asc Description: OpenPGP digital signature
Re: Side-by-side configuration is incorrect reported as permission denied
Thanks guys! That is a great news cygwin1.dll returns ELIBADD natively (which, as of today's patches, it does) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: imagemagick errors under cygwin on 64-bit Win 7 system
Paul Thompson wrote: Marco: I followed the error reporting directions. How long is the usual wait for a response? I've only found two messages from you on this list: - http://cygwin.com/ml/cygwin/2012-08/msg00251.html - http://cygwin.com/ml/cygwin/2012-08/msg00297.html This implies you've sent your full problem report (ie including the diagnostics the problems page requests and the ones Marco prompted for) somewhere off-list. This list is the correct place for problem reports, and unless explicitly requested, you should keep replies here too. Possibly I've misunderstood, in which case I apologize. If not, you'll get a much better response if you send your full problem report to this mailing list. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
git svn problem after upgrading to perl 5.14.2.3
Hello, after updating Cygwin, git svn fails with the following message: Password for 'ibr': Can't locate Term/ReadKey.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/site_perl/5.14 /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int /usr/lib/perl5/vendor_perl/5.14 /usr/lib/perl5/5.14/i686-cygwin-threads-64int /usr/lib/perl5/5.14 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 .) at /usr/lib/git-core/git-svn line 4428. I had to install perl_vendor to get it to work. Should git-svn or subversion-perl depend on perl_vendor? With kind regards, Baurzhan. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
On 8/14/2012 11:14 AM, Adam Dinwoodie wrote: Paul Thompson wrote: Marco: I followed the error reporting directions. How long is the usual wait for a response? I've only found two messages from you on this list: - http://cygwin.com/ml/cygwin/2012-08/msg00251.html - http://cygwin.com/ml/cygwin/2012-08/msg00297.html This implies you've sent your full problem report (ie including the diagnostics the problems page requests and the ones Marco prompted for) somewhere off-list. This list is the correct place for problem reports, and unless explicitly requested, you should keep replies here too. Possibly I've misunderstood, in which case I apologize. If not, you'll get a much better response if you send your full problem report to this mailing list. Paul, I received nothing directly, nor I found anything blocked in the google spam filter, could you please recheck and/or resend the info ? I any case, Adam's comments are fully appropriate: if you want an help you need to provide us all the info about your system plus how to replicate your problem. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh logon failure
On 8/13/2012 5:49 AM, thebardingreen wrote: I'm having this exact problem. Did you guys ever solve it? No. Also as now I have further issue with sshd http://cygwin.com/ml/cygwin/2012-07/msg00649.html I suspect that in both case my corporate enviroment is interfering. Probably the Novell driver or a BLODA or the security policy; e.g. cyg_server right to logon as a service is reset at every boot, so there are likely other settings like that impacting my user. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Side-by-side configuration is incorrect reported as permission denied
On Tue, Aug 14, 2012 at 10:37:51AM +0200, Pawel Jasinski wrote: Thanks guys! That is a great news It isn't entirely clear that you understand that what just happened is what we always do when we find a Windows error which we haven't translated and for which there is better translation than EACCES. I asked for suggestions, we got a good one, and I changed Cygwin. I wonder if much of this whole thread has just been a misconception about that SOP. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
On Aug 14 09:15, Paul Thompson wrote: I thought I submitted to the right queue, but clearly did not. Perhaps my mail did not get received. I have run cygcheck as requested and attached the output cygcheck.out to this email I run the following commands: d2u dirlist.txt convert Brausch 1946-1950-901.jpg -resize 30@ -filter Lanczos -adaptive-sharpen 2x3 -quality 95 -sampling-factor 2x1 zimg002.miff montage -label D Brausch Wedding,1951 zimg002.miff -font Arial -pointsize 20 -frame 40 -geometry +0+0 zimg002.png I ran these commands using cygwin imagemagick downloaded independently, and all runs cleanly. Under cygwin imagemagick, I get errors as shown below. The convert command works seems to run fine (no errors). With the montage command, I get: unix: converting file dirlist.txt to Unix format ... 0 [main] montage 7796 C:\cygwin\bin\montage.exe: *** fatal error in forked process - failed to create new win32 semaphore, error -2 0 [main] montage 8960 C:\cygwin\bin\montage.exe: *** fatal error in forked process - failed to create new win32 semaphore, error -2 Wow. That's rather unexpected. Unfortunately the error code -2 is just an artefact, not the actual error code. I fixed that in CVS. Did you try if rebaseall fixes this issue? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: CMake 2.8.9-1
CMake 2.8.9-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - the new Ninja generator is now enabled by default on Windows (and now Mac, too!) - added POSITION_INDEPENDENT_CODE target property, automatically adds -fPIC and -fPIE for compilers that require it - added -Dvar=value command line handling to ctest - added MUMPS coverage support to ctest, including GTM and Cache - and, as always, various minor bug fixes The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=93 Following is the complete list of changes in this release, including changes introduced in every release candidate. Please upgrade to this latest and greatest version of CMake for building your projects. Changes in CMake 2.8.9 (since 2.8.9-rc3) None Changes in CMake 2.8.9-rc3 (since 2.8.9-rc2) Alexey Ozeritsky (1): Fixed: FindLAPACK does not find MKL 10.3 when using gcc 4.x Brad King (3): pre-commit: Reject C++ code with lines too long Tests/X11: Add missing include stdlib.h for 'rand' Tests/ObjC++: Use standard iostream header David Cole (1): CPack: Use bin subdir when looking for dpkg and rpmbuild Eric NOULARD (2): Do not run cpack at CMake time it is not available. Find dpkg and rpmbuild in usual Fink and MacPort paths Nicolas Despres (17): Ninja: Cannot pass a reference to an anonymous object. Ninja: Add support for OS X app bundles. Ninja: Add support for OX X library framework. Ensure 3rd party libraries are writable. Remove trailing white-spaces. Re-factor OS X bundle and framework generation. Ninja: Copy resource files in the bundle. Ninja: Add support for CFBundle. Enable BundleTest with CLang too. Re-factor CFBundle generation. Ninja: Use same echo message as makefiles. Re-factor bundle content copying rules generation. Re-factor Mac OS X content directory computation. Re-factor framework directory computation. Re-factor OS X content generator start up. Fix memory leak in Makefile generator. Add missing this-. Peter Kuemmel (1): Ninja: dep files and multiple -arch flags not possible on mac Peter Kümmel (24): Ninja: windres is also used for cross-compiling Ninja: search for windres with prefix Ninja: there could be null pointers Ninja: more searching for windres Ninja: path is already declared Ninja: fix GCC 4.7 warning -Wconversion Ninja: fix sytle Ninja: also stop when .rc's .d file couldn't be generated Ninja: readd quotes to src file path before patching it Ninja: cmcldeps needs absolute paths for RCs Ninja: on Mac no multiple -arch because of -M Ninja: fix mis-matching endif() argument Ninja: also mingw needs TARGET_PDB Ninja: line length Ninja: make TARGET_PDB a real .gdb file name Ninja: make debug symbol suffix configurable by CMAKE_DEBUG_SYMBOL_SUFFIX Ninja: remove 'friend' in ninja code Ninja: remove warnings Ninja: remove 'this' from member initializer list Ninja: fixes for bcc Ninja: enable ninja on Mac so all Mac CDash-builds are tested, cleanup later Ninja: void function can't return a value Ninja: enable ninja support everywhere Ninja: also bootstrap ninja files Changes in CMake 2.8.9-rc2 (since 2.8.9-rc1) Alex Neundorf (4): -remove trailing whitespace documentation: preparation for making the man section configurable man documentation: detect man section from the given filename Eclipse: fix #13313, always set LANG to C, also if unset Bill Hoffman (1): Remove process execution code from cmcldeps and have it use cmake code. Brad King (12): KWIML: Generalize interface to report broken integer literal macros KWIML: Teach ABI.h about 'long long' and 'char' on old HP KWIML: Teach INT.h that no HP platform implements SCN*8 formats KWIML: Teach INT about broken UINT32_C on old HP Fix project command documentation typo (#13384) CTestUpdateSVN: Do not create repo directory first (#13349) Tests/CustomCommand: Do not use 'main' in a library AIX-GNU: Link shared libs with -brtl,-bnoipath (#13352) include: Ignore empty string as file name (#13388) Add ASM platform information for GNU compiler on AIX (#13390) if: Document that macro arguments are not variables (#13393) install: Fix COMPONENT option Clinton Stimpson (3): GetPrerequisites.cmake: detect executables built with the -pie linker flag. cmake-gui: Fix code to respect current locale. DeployQt4: workaround bug 13258 where ARGV1 is leaked into a sub function. David Cole (7): STYLE: Fix line
Re: [ANNOUNCEMENT] Updated: texlive-collection-basic-20120628-2 (TEST)
Ken Brown kbrown at cornell.edu writes: Please test it and report any problems to the Cygwin mailing list. It would be especially helpful if you would look at /var/log/setup.log.full after installing it, and make sure there are no errors involving updmap. I've only now been able to check the test package. I still get these messeges with my setup (as before), but I believe they are harmless. updmap is using the following updmap.cfg files (in precedence order): /etc/texmf/web2c/updmap.cfg /usr/share/texmf/web2c/updmap.cfg updmap: generated map otf-noEmbed.map (from otf-@kanjiEmbed@.map) does not exists, not activating it! updmap: generated map otf-up-noEmbed.map (from otf-up-@kanjiEmbed@.map) does not exists, not activating it! updmap: generated map ptex-noEmbed.map (from ptex-@kanjiEmbed@@kanjiVariant@.map) does not exists, not activating it! I have an (empty) /usr/share/texmf-site directory, I could try again without it if you think that would be helpful. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
Wow. That's rather unexpected. Unfortunately the error code -2 is just an artefact, not the actual error code. I fixed that in CVS. Did you try if rebaseall fixes this issue? OK, I just learned about rebaseall. I am not actually on the machine in question, and will try this tonight. I will report tomorrow on results. I will say that I did just do a fresh install of cygwin for this. Should cygwin work straight out of the box, or is the rebaseall needed to tailor to specific machine? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
On 8/14/2012 11:56 AM, Paul Thompson wrote: Wow. That's rather unexpected. Unfortunately the error code -2 is just an artefact, not the actual error code. I fixed that in CVS. Did you try if rebaseall fixes this issue? OK, I just learned about rebaseall. I am not actually on the machine in question, and will try this tonight. I will report tomorrow on results. I will say that I did just do a fresh install of cygwin for this. Should cygwin work straight out of the box, or is the rebaseall needed to tailor to specific machine? If you just went to cygwin.com and installed using the setup.exe link from there, then you shouldn't need to take the added step of running rebaseall if all else about the installation is proper. Still, it won't hurt to try it. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
On Aug 14 10:56, Paul Thompson wrote: Wow. That's rather unexpected. Unfortunately the error code -2 is just an artefact, not the actual error code. I fixed that in CVS. Did you try if rebaseall fixes this issue? OK, I just learned about rebaseall. I am not actually on the machine in question, and will try this tonight. I will report tomorrow on results. I will say that I did just do a fresh install of cygwin for this. Should cygwin work straight out of the box, or is the rebaseall needed to tailor to specific machine? There's autorebase, which is called from setup, but the method is not entirely foolproof. If you installed exactly once and then don't start setup again unless new packages are available, you're ok, but if you start setup a couple of times to install more packages you forgot in the first run, then autorebase won't be triggered and the DLLs installed in the subsequent setup runs won't be rebased. A manual rebaseall will fix that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: texlive-collection-basic-20120628-2 (TEST)
On 8/14/2012 11:53 AM, Achim Gratz wrote: Ken Brown kbrown at cornell.edu writes: Please test it and report any problems to the Cygwin mailing list. It would be especially helpful if you would look at /var/log/setup.log.full after installing it, and make sure there are no errors involving updmap. I've only now been able to check the test package. I still get these messeges with my setup (as before), but I believe they are harmless. Yes, but still I'd like to get rid of them. updmap is using the following updmap.cfg files (in precedence order): /etc/texmf/web2c/updmap.cfg /usr/share/texmf/web2c/updmap.cfg updmap: generated map otf-noEmbed.map (from otf-@kanjiEmbed@.map) does not exists, not activating it! updmap: generated map otf-up-noEmbed.map (from otf-up-@kanjiEmbed@.map) does not exists, not activating it! updmap: generated map ptex-noEmbed.map (from ptex-@kanjiEmbed@@kanjiVariant@.map) does not exists, not activating it! I would have expected updmap-sys --syncwithtrees (which is in the texlive-collection-basic postinstall script) to get rid of those messages. Maybe those messages were produced earlier in the postinstall process. Please try running `updmap-sys' and see if you still get the error messages. If so, maybe try running `updmap-sys --syncwithtrees' and then try updmap-sys again. I have an (empty) /usr/share/texmf-site directory, I could try again without it if you think that would be helpful. No, I think you need that directory in order to prevent updmap from just quitting without doing anything. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
There's autorebase, which is called from setup, but the method is not entirely foolproof. If you installed exactly once and then don't start setup again unless new packages are available, you're ok, but if you start setup a couple of times to install more packages you forgot in the first run, then autorebase won't be triggered and the DLLs installed in the subsequent setup runs won't be rebased. A manual rebaseall will fix that. And that is exactly what I did - I ran setup several times to add stuff. I will do the manual rebaseall -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please test snapshots
Hi, I think i found a glitch in gmon.c
the testcase is following. and you can see it doesn't work.
int main()
{
char *proffile;
{
char gmon_out[] = gmon.out;
proffile = gmon_out;
}
printf(%s\n,proffile);
}
---
$ ./a
a(▒
Actually the above can't be expected to work. the above is exactly same
case with gmon.c:206
-- Regards.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
On 8/14/2012 7:44 PM, Paul Thompson wrote: There's autorebase, which is called from setup, but the method is not entirely foolproof. If you installed exactly once and then don't start setup again unless new packages are available, you're ok, but if you start setup a couple of times to install more packages you forgot in the first run, then autorebase won't be triggered and the DLLs installed in the subsequent setup runs won't be rebased. A manual rebaseall will fix that. And that is exactly what I did - I ran setup several times to add stuff. I will do the manual rebaseall Paul, it is not a rebase error. It is ImageMagick mishandling the missing font. GraphickMagick equivalent is correctly handling the case and the error message is more clear. $ gm montage -label D Brausch Wedding,1951 zimg002.miff -font Arial -pointsize 20 -frame 40 -geometry +0+0 zimg002.png gm montage: Unable to read font (arial.ttf) [No such file or directory]. The workaround for both montage and gm montage is to copy arial.ttf in the current directory something like cp /cygdrive/c/Windows/Fonts/arial.ttf . ImageMagick is also able to use the TTF font if installed in the X directory /usr/share/fonts/TTF and montage is run inside xterm instead of mintty. GM is not handling such case, but I have no time to investigate. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please test snapshots
On Aug 15 02:59, jojelino wrote:
Hi, I think i found a glitch in gmon.c
the testcase is following. and you can see it doesn't work.
int main()
{
char *proffile;
{
char gmon_out[] = gmon.out;
proffile = gmon_out;
}
printf(%s\n,proffile);
}
---
$ ./a
a(▒
Actually the above can't be expected to work. the above is exactly
same case with gmon.c:206
Fixed in CVS.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please test snapshots
On Tue, Aug 14, 2012 at 09:39:14PM +0200, Corinna Vinschen wrote:
On Aug 15 02:59, jojelino wrote:
Hi, I think i found a glitch in gmon.c
the testcase is following. and you can see it doesn't work.
int main()
{
char *proffile;
{
char gmon_out[] = gmon.out;
proffile = gmon_out;
}
printf(%s\n,proffile);
}
---
$ ./a
a(???
Actually the above can't be expected to work. the above is exactly
same case with gmon.c:206
Fixed in CVS.
Btw, since this file hadn't changed in two years, it's unlikely
that this was a regression and probably deserved a new subject.
This really isn't an issue with the latest snapshot.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
Paul, it is not a rebase error. It is ImageMagick mishandling the missing font. GraphickMagick equivalent is correctly handling the case and the error message is more clear. $ gm montage -label D Brausch Wedding,1951 zimg002.miff -font Arial -pointsize 20 -frame 40 -geometry +0+0 zimg002.png gm montage: Unable to read font (arial.ttf) [No such file or directory]. The workaround for both montage and gm montage is to copy arial.ttf in the current directory something like cp /cygdrive/c/Windows/Fonts/arial.ttf . ImageMagick is also able to use the TTF font if installed in the X directory /usr/share/fonts/TTF and montage is run inside xterm instead of mintty. GM is not handling such case, but I have no time to investigate. Regards Marco I will try that tonight. The other install of ImageMagick also gave me the arial font error, but handled it more gracefully. Is there some way to getting the fonts on to the path so that I don't need to do the copy around? It seems odd that fonts cannot be located in some sensible manner. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
On 8/14/2012 9:42 PM, Paul Thompson wrote: I will try that tonight. The other install of ImageMagick also gave me the arial font error, but handled it more gracefully. Is there some way to getting the fonts on to the path so that I don't need to do the copy around? It seems odd that fonts cannot be located in some sensible manner. use a font name recognized by unix and not a windows one, eg -font Helvetica to look on font name a use xfontsel from xterm. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin GCC and debug info source file paths
Hi, I didn't know where to put this. I'm trying to use a cygwin build of GCC for arm (binaries from gnuarm.com). When I build a simple dummy application just doing some matrix multiplications in a loop, it creates a nice executable file with debug info, but the path to the source file is a cygwin path which is incompatible with the debugging tool I'm trying to use. I'm wondering if there's a way to generate the exe with relative paths to the source files, alternatively to use windows paths? The tool is Trace32 from Lauterbach, currently experementing with the arm simulator from the website. Mvh David Lindström -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin GCC and debug info source file paths
On 8/14/2012 2:13 PM, David Lindström wrote: Hi, I didn't know where to put this. I'm trying to use a cygwin build of GCC for arm (binaries from gnuarm.com). When I build a simple dummy application just doing some matrix multiplications in a loop, it creates a nice executable file with debug info, but the path to the source file is a cygwin path which is incompatible with the debugging tool I'm trying to use. I'm wondering if there's a way to generate the exe with relative paths to the source files, alternatively to use windows paths? The tool is Trace32 from Lauterbach, currently experementing with the arm simulator from the website. You need to ask the folks at gnuarm.com to make mingw versions of GCC available or use the debugging tools they provide. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Side-by-side configuration is incorrect reported as permission denied
Greetings, Christopher Faylor! But you aren't really even suggesting that. You are apparently just suggesting that every windows error should be displayed by the Cygwin DLL. Wow. Um. On another hand, this made me think from my deep pit: as a regular user, not a developer, in some cases, I would prefer DLL to track and report native error codes/messages. Not as a general way of operation, obviously, more like an intermediate debugging layer on demand. So, there's a suggestion for someone interested in this feature and capable of making this happen. -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.08.2012, 00:38 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
sshd service needs to be restarted after every boot
Hi, I try to run sshd as a service on a windows 7 system. All works fine after I manually stops and start the sshd service (with net stop/start sshd command). But without that the client shows: client@server:/root$ ssh -vvv -p user@windowsPC OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to windowsPC [192.168.0.10] port . debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load /client/.ssh/id_rsa as a RSA1 public key debug1: identity file /client/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /client/.ssh/id_rsa-cert type -1 debug1: identity file /client/.ssh/id_dsa type -1 debug1: identity file /client/.ssh/id_dsa-cert type -1 debug1: identity file /client/.ssh/id_ecdsa type -1 debug1: identity file /client/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0 debug1: match: OpenSSH_6.0 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1 debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [windowsPC]: debug3: load_hostkeys: loading entries for host [windowsPC]: from file /client/.ssh/known_hosts debug3: load_hostkeys: found key type ECDSA in file /client/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent Connection closed by 192.168.0.10 and on the windows host I get an error event from sshd: sshd: PID 1104: fatal: Write failed: Socket operation on non-socket [preauth] The installation and configuration of the sshd-service was made with following steps: 1) Install cygwin with an extra administrator account (Packages: openssh, vim, wget, curl, mc, rsync, shutdown) 2) run ssh-host-config (reply all questions with yes, keep default values for cygwin deamon and name) 3) add rules for the windows firewall and start sshd 4) ssh-copy-id from the client to the windows host I already use sshd on other windows7 systems successfully with the same configuration. There I don't need to restart the sshd service after boot. Regards Jörg Gerlach. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Side-by-side configuration is incorrect reported as permission denied
Hi Christopher, I am sorry I did not understand your comments. I am also not particularly familiar with your COP. I promise to adhere to it in the future. For the patches, I can only blame bad timing. I haven't done cvs up before posting. As you noticed for sure, I am also not so good with rhetoric. Cheers, Pawel On Tue, Aug 14, 2012 at 4:53 PM, Christopher Faylor cgf-use-the-mailinglist-pleasecygwin.com wrote: On Tue, Aug 14, 2012 at 10:37:51AM +0200, Pawel Jasinski wrote: Thanks guys! That is a great news It isn't entirely clear that you understand that what just happened is what we always do when we find a Windows error which we haven't translated and for which there is better translation than EACCES. I asked for suggestions, we got a good one, and I changed Cygwin. I wonder if much of this whole thread has just been a misconception about that SOP. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
persistence of Cygwin message after uninstalling Cygwin
Dear all Although I have (I think) followed completely the instructions for removing Cygwin from my computer, I keep on receiving warning and error messages that are Cygwin related when I work under the Windows command line . The complete background to this is as follows: * When I tried to install a package in the R language under Windows (http://cran.r-project.org/bin/windows/Rtools/) , the installation failed. The installation requires a few command line instructions. As the cause for this failure was not clear, I have also tried to install this package under Cygwin. This installation did work out correctly. However, due to memory limitations, I could not use the package under Cygwin. * In the meanwhile, the reason for the failure of the installation under Windows had become clear (it was due to a typo in the path definition). When I subsequently tried to install the package under R, I got Cygwin warnings pointing to MS DOS path formats. More importantly, the installation of my pacakge failed again. * Setting the environment variable to nodosfilewarning did not change anything to the warning message I received. I have then completely removed Cygwin from my computer, following the detailed instructions on the website (http://cygwin.com/faq-nochunks.html#faq.setup.uninstall-all ), including deleting the registry tree Software\Cygwin under HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. * However, both the warning message and the installation errors persists, even after restarting the computer. The log of the failed installation includes: g++ -IC:/R/R-215~1.0/include -DNDEBUG -O2 -Wall -mtune=core2 -c short_path_R.cc -o short_path_R.o g++: not found make: *** [short_path_R.o] Error 127 When I look at the format of the path in this error message, I have the impression that this error is Cygwin related, rather than an error in R itself. Does anyone have an idea what is going on here? (the log also includes the warning messages related to the MS DOS path formats and similar error messages to the one above). Laurent Franckx VITO NV Boeretang 200, 2400 MOL, Belgium Tel. + 32 14 33 58 22 Skype: laurent.franckx laurent.fran...@vito.be http://www.vito.be/e-maildisclaimer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: persistence of Cygwin message after uninstalling Cygwin
On 8/14/2012 5:37 PM, Franckx Laurent wrote: Dear all Although I have (I think) followed completely the instructions for removing Cygwin from my computer, I keep on receiving warning and error messages that are Cygwin related when I work under the Windows command line . snip When I look at the format of the path in this error message, I have the impression that this error is Cygwin related, rather than an error in R itself. Does anyone have an idea what is going on here? (the log also includes the warning messages related to the MS DOS path formats and similar error messages to the one above). According to the R-project site, it's using Cygwin tools. Presumably the complaints that you're getting are coming from those tools that were installed with R. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin GCC and debug info source file paths
On Tue, Aug 14, 2012 at 11:13 AM, David Lindström i...@davidlindstrom.se wrote: Hi, I didn't know where to put this. I'm trying to use a cygwin build of GCC for arm (binaries from gnuarm.com). When I build a simple dummy application just doing some matrix multiplications in a loop, it creates a nice executable file with debug info, but the path to the source file is a cygwin path which is incompatible with the debugging tool I'm trying to use. I'm wondering if there's a way to generate the exe with relative paths to the source files, alternatively to use windows paths? The tool is Trace32 from Lauterbach, currently experementing with the arm simulator from the website. You may be able to use GCC's -fdebug-prefix-map option. Ian -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Question about UAC and bash/cygwin
Hi Folks, I've scanned months of the mailing list archives for an answers and searched until I've run out of ideas. What I want to figure out is this. When I run bash --login -i in an elevated command prompt, or I use elevate bash --login -i or any other variation, I don't get any sign of being root or having privileges. But, I can invoke privileged operations and use chmod, chown, etc. on files and read, write,delete in Administrator only directories from bash. These are places you can only change in a raised privilege state. My /etc/passwd and /etc/group have been automatically created and updated to have user root connected to the S-1-5-32-544 sid as I think I saw in one of the guides. My local administrator account has the username admin. Problems 1) Example, id still shows my normal userid and default group of 'none even though I am a member of root's (Administrators) group. None of the scripts that check for administrator level seem to work. Am i doing it wrong? 2) I can't ssh into the box as root because there is no group password in Windows 7. Should there be a way to assign own? 3) If I use the local administrators account, none of the files or directories has root as user or group. But shouldn't they? 4) There is no newgrp command so I can't join any of my other assigned groups. So, umask doesn't do as I want. If there a better way to change to the root group? 5) When I ran sshd-host-config I get a slew of warnings about not being able to do that (on both .\Administrator and on elevated normal login). However, the service is created and the users cyg_server and sshd are as well with the proper groups and privileges. Howver, it fails to set the owner or access rights on /etc/ssh* or /var/log/sshd or /var/log/lastlog. What is the proper way to have done this on WIndows 7 Ultimate Edition 64-bit Service Pack I? 6) Cygwin is a great package and works better than SFU/SUA which I also have installed. Is there any way I can help make the security stuff more unixy? Thanks in advance for any answers or replies. -- Lord Laraby -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: imagemagick errors under cygwin on 64-bit Win 7 system
Marco gets the diagnostic prize!! Font name was the issue. Used -font Helvetica, and all went like a charm!! So, thank you, Marco. use a font name recognized by unix and not a windows one, eg -font Helvetica to look on font name a use xfontsel from xterm. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about UAC and bash/cygwin
Okay, some of this has been covered here: http://www.cygwin.com/ml/cygwin/2008-10/msg00370.html I'm still reading more and doing more detective work. -- Lord Laraby -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Side-by-side configuration is incorrect reported as permission denied
On Wed, Aug 15, 2012 at 12:42:09AM +0400, Andrey Repin wrote: Greetings, Christopher Faylor! Sigh. But you aren't really even suggesting that. You are apparently just suggesting that every windows error should be displayed by the Cygwin DLL. Wow. Um. On another hand, this made me think from my deep pit: as a regular user, not a developer, in some cases, I would prefer DLL to track and report native error codes/messages. Not as a general way of operation, obviously, more like an intermediate debugging layer on demand. So, there's a suggestion for someone interested in this feature and capable of making this happen. If you're debugging you can get the error by stepping into the DLL. If you are actually capable of making it happen then prove it by discussing implementation in cygwin-developers and eventually providing a patch in cygwin-patches. Otherwise, take Earnie's observation to heart: http://cygwin.com/ml/cygwin/2012-08/msg00257.html (I'm going to be quoting this a lot) You aren't making any points by posting YA vague suggestion. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Side-by-side configuration is incorrect reported as permission denied
On Tue, Aug 14, 2012 at 11:35:02PM +0200, Pawel Jasinski wrote: I am sorry I did not understand your comments. I am also not particularly familiar with your COP. I promise to adhere to it in the future. For the patches, I can only blame bad timing. I haven't done cvs up before posting. As you noticed for sure, I am also not so good with rhetoric. Please honor my wishes. There is quite obviously no reason for you to send me private email about this. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Another sigwaitinfo problem (with testcase)
When run on a Linux machine, this program starts up and blocks on sigwaitinfo.
You can suspend and resume the program using usual job control facilities, and
on SIGINT, the program prints a message and exits. When the program resumes
after being stopped, it prints resumed.
With the 2012-08-07 Cygwin snapshot, this program prints resumed immediately
after receiving SIGTSTP, then fails to respond to any signal, even signals not
in the blocked set. A simpler test program that just calls raise (SIGSTOP)
property stops itself before resuming execution.
#define _GNU_SOURCE 1
#include unistd.h
#include stdio.h
#include stdlib.h
#include signal.h
#include pthread.h
int
main()
{
sigset_t waitmask;
int sig;
sigemptyset (waitmask);
sigaddset (waitmask, SIGTSTP);
sigaddset (waitmask, SIGINT);
sigprocmask (SIG_BLOCK, waitmask, NULL);
for (;;) {
sig = sigwaitinfo (waitmask, NULL);
fprintf (stderr, got %s\n, sys_siglist[sig]);
if (sig == SIGTSTP) {
raise (SIGSTOP); /* Block until somebody resumes us. */
} else if (sig == SIGINT) {
fprintf(stderr, exiting);
break;
}
}
return 0;
}
signature.asc
Description: OpenPGP digital signature
Updated: CMake 2.8.9-1
CMake 2.8.9-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - the new Ninja generator is now enabled by default on Windows (and now Mac, too!) - added POSITION_INDEPENDENT_CODE target property, automatically adds -fPIC and -fPIE for compilers that require it - added -Dvar=value command line handling to ctest - added MUMPS coverage support to ctest, including GTM and Cache - and, as always, various minor bug fixes The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=93 Following is the complete list of changes in this release, including changes introduced in every release candidate. Please upgrade to this latest and greatest version of CMake for building your projects. Changes in CMake 2.8.9 (since 2.8.9-rc3) None Changes in CMake 2.8.9-rc3 (since 2.8.9-rc2) Alexey Ozeritsky (1): Fixed: FindLAPACK does not find MKL 10.3 when using gcc 4.x Brad King (3): pre-commit: Reject C++ code with lines too long Tests/X11: Add missing include stdlib.h for 'rand' Tests/ObjC++: Use standard iostream header David Cole (1): CPack: Use bin subdir when looking for dpkg and rpmbuild Eric NOULARD (2): Do not run cpack at CMake time it is not available. Find dpkg and rpmbuild in usual Fink and MacPort paths Nicolas Despres (17): Ninja: Cannot pass a reference to an anonymous object. Ninja: Add support for OS X app bundles. Ninja: Add support for OX X library framework. Ensure 3rd party libraries are writable. Remove trailing white-spaces. Re-factor OS X bundle and framework generation. Ninja: Copy resource files in the bundle. Ninja: Add support for CFBundle. Enable BundleTest with CLang too. Re-factor CFBundle generation. Ninja: Use same echo message as makefiles. Re-factor bundle content copying rules generation. Re-factor Mac OS X content directory computation. Re-factor framework directory computation. Re-factor OS X content generator start up. Fix memory leak in Makefile generator. Add missing this-. Peter Kuemmel (1): Ninja: dep files and multiple -arch flags not possible on mac Peter Kümmel (24): Ninja: windres is also used for cross-compiling Ninja: search for windres with prefix Ninja: there could be null pointers Ninja: more searching for windres Ninja: path is already declared Ninja: fix GCC 4.7 warning -Wconversion Ninja: fix sytle Ninja: also stop when .rc's .d file couldn't be generated Ninja: readd quotes to src file path before patching it Ninja: cmcldeps needs absolute paths for RCs Ninja: on Mac no multiple -arch because of -M Ninja: fix mis-matching endif() argument Ninja: also mingw needs TARGET_PDB Ninja: line length Ninja: make TARGET_PDB a real .gdb file name Ninja: make debug symbol suffix configurable by CMAKE_DEBUG_SYMBOL_SUFFIX Ninja: remove 'friend' in ninja code Ninja: remove warnings Ninja: remove 'this' from member initializer list Ninja: fixes for bcc Ninja: enable ninja on Mac so all Mac CDash-builds are tested, cleanup later Ninja: void function can't return a value Ninja: enable ninja support everywhere Ninja: also bootstrap ninja files Changes in CMake 2.8.9-rc2 (since 2.8.9-rc1) Alex Neundorf (4): -remove trailing whitespace documentation: preparation for making the man section configurable man documentation: detect man section from the given filename Eclipse: fix #13313, always set LANG to C, also if unset Bill Hoffman (1): Remove process execution code from cmcldeps and have it use cmake code. Brad King (12): KWIML: Generalize interface to report broken integer literal macros KWIML: Teach ABI.h about 'long long' and 'char' on old HP KWIML: Teach INT.h that no HP platform implements SCN*8 formats KWIML: Teach INT about broken UINT32_C on old HP Fix project command documentation typo (#13384) CTestUpdateSVN: Do not create repo directory first (#13349) Tests/CustomCommand: Do not use 'main' in a library AIX-GNU: Link shared libs with -brtl,-bnoipath (#13352) include: Ignore empty string as file name (#13388) Add ASM platform information for GNU compiler on AIX (#13390) if: Document that macro arguments are not variables (#13393) install: Fix COMPONENT option Clinton Stimpson (3): GetPrerequisites.cmake: detect executables built with the -pie linker flag. cmake-gui: Fix code to respect current locale. DeployQt4: workaround bug 13258 where ARGV1 is leaked into a sub function. David Cole (7): STYLE: Fix line
