setup: simplify SUBDIRS
Right now, make clean (or the other *clean targets) does not clean in
libgetopt++. Unless there is something I'm not aware of, libgetopt++
can be handled like any other SUBDIRS, so that all targets are passed
down to it as well. Patch attached.
Yaakov
2010-08-10 Yaakov Selkowitz yselkow...@users.sourceforge.net
* Makefile.am: Treat libgetopt++ as full-fledged SUBDIRS.
(setup_LDADD): Always link against included libgetopt++.
Index: Makefile.am
===
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.82
diff -u -r2.82 Makefile.am
--- Makefile.am 29 Jul 2010 13:09:54 - 2.82
+++ Makefile.am 10 Aug 2010 06:46:57 -
@@ -15,9 +15,7 @@
#
# Makefile for Cygwin installer
-INST_SUBDIRS:=...@subdirs@
-DIST_SUBDIRS:=${INST_SUBDIRS} tests
-SUBDIRS:=tests
+SUBDIRS := @subdirs@ tests
## DISTCLEANFILES = include/stamp-h include/stamp-h[0-9]*
@@ -63,8 +61,7 @@
# knows about that already)
BUILT_SOURCES = \
setup_version.c \
- iniparse.h \
- ${INST_SUBDIRS}
+ iniparse.h
CLEANFILES = setup_version.c
@@ -115,7 +112,7 @@
setup_LDADD = \
libinilex.a \
- -Linst/lib -lgetopt++ -lgcrypt -lgpg-error \
+ libgetopt++/libgetopt++.la -lgcrypt -lgpg-error \
-lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -luuid -llzma -lbz2 -lz
setup_LDFLAGS = -mwindows -Wl,-static -static-libtool-libs
setup_SOURCES = \
@@ -308,6 +305,3 @@
sort | tar -T - -cjf ${CURDIR}/$$ver-src.tar.bz2;\
echo $$ver-src.tar.bz2; exec rm -f $$ver
-.PHONY: ${INST_SUBDIRS}
-${INST_SUBDIRS}:
- ${MAKE} -C $@ install
Re: setup: simplify SUBDIRS
On Tue, Aug 10, 2010 at 01:57:56AM -0500, Yaakov (Cygwin/X) wrote: Right now, make clean (or the other *clean targets) does not clean in libgetopt++. Unless there is something I'm not aware of, libgetopt++ can be handled like any other SUBDIRS, so that all targets are passed down to it as well. Patch attached. Hmm. I could have sworn that it used to clean in that subdirectory. Please check in. Thanks. cgf
New setup.exe uploaded
I've uploaded a new setup.exe. FYI cgf
Re: ITP: rtorret, libtorrent, libsigc++
On 8 August 2010 17:03, Chris Sutcliffe wrote: Valid point. I'll change the hint files for libtorrent and libsigc++ and upload new versions shortly. Done: libsigc++-2.0-2.2.8-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc++/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/libsigc++2.0_0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/libsigc++2.0-devel-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/libsigc++2.0-doc-2.2.8-1.tar.bz2 libtorrent-0.12.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libtorrent/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/libtorrent11-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/libtorrent-devel-0.12.6-1.tar.bz2 rtorrent-0.8.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/setup.hint \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1.tar.bz2 Chuck / Steven, does this latest packaging capture all your proposed changes appropriately? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: ITP: rtorret, libtorrent, libsigc++
On Tue, 2010-08-10 at 13:33 -0400, Chris Sutcliffe wrote: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc++/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0_0/libsigc++2.0_0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-devel/libsigc++2.0-devel-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/setup.hint \ http://emergedesktop.org/cygwin/libsigc++/libsigc++2.0-doc/libsigc++2.0-doc-2.2.8-1.tar.bz2 Can you please make the naming of these packages match those in Ports so that I don't have to adjust all my packages unnecessarily? Yaakov
[PATCH] setup: gcc-4.x compatibility
This patch fixes several issues compiling setup.exe with gcc-4.x while
retaining compatibility with gcc-3.4, as tested with gcc-mingw-3.4.4-999
and my mingw-gcc-4.5.1 sample build. Once we switch to a proper
mingw-gcc cross-compiler, the only change that will need to be made is
to CC/CXX in doconfigure.
OK to apply?
Yaakov
2010-08-10 Yaakov Selkowitz yselkow...@users.sourceforge.net
Fix compatibility with GCC 4.x.
* Makefile.am (setup_LDFLAGS): Pass -static to compiler instead of
linker so that libgcc is statically linked as well.
(autoload.o): Disable optimization.
* localdir.cc (browse_cb): Fix jump to case label crosses
initialization error.
* mklink2.cc (sfli): Fix non-local variable uses anonymous type
warning.
* ntdll.h: Fix redeclared without dllimport attribute: previous
dllimport ignored warnings.
* package_message.h (display): Fix 'exit' was not declared in this
scope error.
Index: Makefile.am
===
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.81
diff -u -r2.81 Makefile.am
--- Makefile.am 8 Apr 2010 15:50:38 - 2.81
+++ Makefile.am 23 Jul 2010 17:01:14 -
@@ -114,7 +114,7 @@
libinilex.a \
libgetopt++/libgetopt++.la -lgcrypt -lgpg-error \
-lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -luuid -llzma -lbz2 -lz
-setup_LDFLAGS = -mwindows -Wl,-static -static-libtool-libs
+setup_LDFLAGS = -mwindows -Wc,-static -static-libtool-libs
setup_SOURCES = \
AntiVirus.cc \
AntiVirus.h \
@@ -283,6 +283,9 @@
libmd5-rfc/md5.c \
libmd5-rfc/md5.h
+# autoload code does not optimize well
+autoload.o: CFLAGS += -O0
+
VER := $(shell sed -ne 's/^\$$Revi[s]ion: *\([^ ]*\) *$$.*/\1/p' \
$(srcdir)/ChangeLog)
Index: localdir.cc
===
RCS file: /cvs/cygwin-apps/setup/localdir.cc,v
retrieving revision 2.36
diff -u -r2.36 localdir.cc
--- localdir.cc 2 Feb 2010 17:28:10 - 2.36
+++ localdir.cc 23 Jul 2010 17:01:14 -
@@ -152,12 +152,14 @@
SendMessage (h, BFFM_SETSELECTION, TRUE, (LPARAM) local_dir.c_str());
break;
case BFFM_SELCHANGED:
- // Make a note of each new dir we successfully select, so that
- // we know where to create the new directory if an invalid name
- // is entered in the text box.
- LPITEMIDLIST pidl = reinterpret_castLPITEMIDLIST(lp);
- SHGetPathFromIDList (pidl, dirname);
- break;
+ {
+// Make a note of each new dir we successfully select, so that
+// we know where to create the new directory if an invalid name
+// is entered in the text box.
+LPITEMIDLIST pidl = reinterpret_castLPITEMIDLIST(lp);
+SHGetPathFromIDList (pidl, dirname);
+break;
+ }
case BFFM_VALIDATEFAILED:
// See if user wants to create a dir in the last successfully-selected.
CHAR tempname[MAX_PATH];
Index: mklink2.cc
===
RCS file: /cvs/cygwin-apps/setup/mklink2.cc,v
retrieving revision 2.11
diff -u -r2.11 mklink2.cc
--- mklink2.cc 18 Dec 2009 11:59:54 - 2.11
+++ mklink2.cc 23 Jul 2010 17:01:14 -
@@ -111,7 +111,7 @@
: mkcygsymlink_9x (from, to);
}
-struct {
+static struct {
FILE_LINK_INFORMATION fli;
WCHAR namebuf[32768];
} sfli;
Index: ntdll.h
===
RCS file: /cvs/cygwin-apps/setup/ntdll.h,v
retrieving revision 2.2
diff -u -r2.2 ntdll.h
--- ntdll.h 13 May 2009 11:28:34 - 2.2
+++ ntdll.h 23 Jul 2010 17:01:14 -
@@ -14,6 +14,8 @@
#ifndef SETUP_NTDLL_H
#define SETUP_NTDLL_H
+#define NTOSAPI
+
#include ddk/ntapi.h
#include ddk/ntifs.h
Index: package_message.h
===
RCS file: /cvs/cygwin-apps/setup/package_message.h,v
retrieving revision 1.2
diff -u -r1.2 package_message.h
--- package_message.h 22 Dec 2009 16:19:51 - 1.2
+++ package_message.h 23 Jul 2010 17:01:14 -
@@ -15,6 +15,7 @@
#include UserSettings.h
#include state.h
+#include stdlib.h
#include windows.h
class packagemessage
Re: [PATCH] setup: gcc-4.x compatibility
On Tue, Aug 10, 2010 at 02:46:11PM -0500, Yaakov (Cygwin/X) wrote: This patch fixes several issues compiling setup.exe with gcc-4.x while retaining compatibility with gcc-3.4, as tested with gcc-mingw-3.4.4-999 and my mingw-gcc-4.5.1 sample build. Once we switch to a proper mingw-gcc cross-compiler, the only change that will need to be made is to CC/CXX in doconfigure. OK to apply? Yes. Thanks. cgf
Re: ITP: rtorret, libtorrent, libsigc++
On 10 August 2010 14:03, Yaakov (Cygwin/X) wrote: Can you please make the naming of these packages match those in Ports so that I don't have to adjust all my packages unnecessarily? I've repackaged libsigc++2.0 as libsigc2.0: libsigc2.0-2.2.8-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libsigc/setup.hint \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-2.2.8-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0_0/setup.hint \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0_0/libsigc++2.0_0-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-devel/setup.hint \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-devel/libsigc++2.0-devel-2.2.8-1.tar.bz2 \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-doc/setup.hint \ http://emergedesktop.org/cygwin/libsigc/libsigc2.0-doc/libsigc++2.0-doc-2.2.8-1.tar.bz2 libtorrent-0.12.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/libtorrent/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent11/libtorrent11-0.12.6-1.tar.bz2 \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/setup.hint \ http://emergedesktop.org/cygwin/libtorrent/libtorrent-devel/libtorrent-devel-0.12.6-1.tar.bz2 rtorrent-0.8.6-1: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/rtorrent/setup.hint \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1-src.tar.bz2 \ http://emergedesktop.org/cygwin/rtorrent/rtorrent-0.8.6-1.tar.bz2 Please let me know if there any additional changes required. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
[PATCH] setup: build enhancements
This patch for setup contains a few build-system enhancements: * Bail out of configure if prereqs are missing. I decided to check for headers instead of libs to avoid possible stdcall issues with the latter. I'm not sure whether this will make such a difference with gcc-3 -mno-cygwin (which IIUC is susceptible to find the native versions' headers in /usr/include instead), but it will when proper cross-compilers are out. * Make doconfigure re-bootstrap if configure.in is newer than configure. Otherwise once you configure, make will essentially autoreconf and run configure a second time. * Remove the special inilex.ll handling by solving the warning which made it necessary. Probably requires a new-ish flex. If future versions of flex or gcc don't get along with -Werror and can't be fixed with flex %option's, an easier (and slightly faster) fix would be to (similar to autoload.c handling): inilex.o: CXXFLAGS += -Wno-unused-function With the flex %option, inilex.o compiles with both gcc-mingw-3.4.4-999 and my mingw-gcc-4.5.1. Yaakov 2010-08-10 Yaakov Selkowitz yselkow...@users.sourceforge.net * configure.in: Check for prerequisites' headers. * doconfigure: Run bootstrap.sh if configure.in is newer than configure. * Makefile.am: Remove libinilex.a library, instead... (inilint_SOURCES): Add inilex.ll. (setup_SOURCES): Ditto. * inilex.ll: Use option nounput to avoid defined but not used warning from yyunput(). Index: configure.in === RCS file: /cvs/cygwin-apps/setup/configure.in,v retrieving revision 2.25 diff -u -r2.25 configure.in --- configure.in 30 Mar 2010 23:55:15 - 2.25 +++ configure.in 10 Aug 2010 21:40:12 - @@ -70,6 +70,15 @@ string \ string.h ) +AC_CHECK_HEADER(zlib.h, , missing_deps=$missing_deps zlib) +AC_CHECK_HEADER(bzlib.h, , missing_deps=$missing_deps libbz2) +AC_CHECK_HEADER(lzma.h, , missing_deps=$missing_deps liblzma) +AC_CHECK_HEADER(gcrypt.h, , missing_deps=$missing_deps libgcrypt) + +if test -n $missing_deps; then + AC_MSG_ERROR([missing prerequisites: $missing_deps]) +fi + prefix=`pwd`/inst; mkdir -p $prefix exec_prefix=$prefix ac_configure_args=$ac_configure_args --disable-shared Index: doconfigure === RCS file: /cvs/cygwin-apps/setup/doconfigure,v retrieving revision 2.2 diff -u -r2.2 doconfigure --- doconfigure 30 Mar 2010 23:55:15 - 2.2 +++ doconfigure 11 Aug 2010 01:10:57 - @@ -4,7 +4,7 @@ DIR=`dirname $0` # Autotool Bootstrap -if [ ! -f $DIR/configure ]; then +if [ ! -f $DIR/configure ] || [ $DIR/configure.in -nt $DIR/configure ]; then echo -e \033[32;1mRunning $DIR/bootstrap.sh\033[0m ( cd $DIR ./bootstrap.sh ) fi Index: Makefile.am === RCS file: /cvs/cygwin-apps/setup/Makefile.am,v retrieving revision 2.84 diff -u -r2.84 Makefile.am --- Makefile.am 10 Aug 2010 20:38:00 - 2.84 +++ Makefile.am 11 Aug 2010 01:14:08 - @@ -74,7 +74,7 @@ endif inilint_LDADD = \ - libinilex.a libgetopt++/libgetopt++.la + libgetopt++/libgetopt++.la inilint_SOURCES = \ filemanip.cc \ filemanip.h \ @@ -86,6 +86,7 @@ LogSingleton.h \ IniDBBuilder.h \ inilintmain.cc \ + inilex.ll \ iniparse.yy \ IniParseFeedback.cc \ IniParseFeedback.h \ @@ -105,13 +106,7 @@ String++.h \ $(inilint_extras) -# workaround to allow omitting -Werror on inilex.cc. -noinst_LIBRARIES = libinilex.a -libinilex_a_SOURCES = inilex.ll -libinilex_a_CXXFLAGS = $(BASECXXFLAGS) - setup_LDADD = \ - libinilex.a \ libgetopt++/libgetopt++.la -lgcrypt -lgpg-error \ -lshlwapi -lcomctl32 -lole32 -lwsock32 -lnetapi32 -luuid -llzma -lbz2 -lz setup_LDFLAGS = -mwindows -Wc,-static -static-libtool-libs @@ -170,6 +165,7 @@ IniDBBuilder.h \ IniDBBuilderPackage.cc \ IniDBBuilderPackage.h \ + inilex.ll \ iniparse.yy \ IniParseFeedback.cc \ IniParseFeedback.h \ Index: inilex.ll === RCS file: /cvs/cygwin-apps/setup/inilex.ll,v retrieving revision 1.3 diff -u -r1.3 inilex.ll --- inilex.ll 30 Jul 2010 14:02:34 - 1.3 +++ inilex.ll 11 Aug 2010 01:14:08 - @@ -35,6 +35,7 @@ %} /*%option debug */ +%option nounput %option noyywrap %option yylineno %option never-interactive
Re: Xorg/CDE bug, fixed in the last Xorg version 1.8.99.905
2010/8/9 Jon TURNEY jon.tur...@dronecode.org.uk:
On 09/08/2010 14:57, Michel Hummel wrote:
2010/8/9 Michel Hummelhummel.mic...@gmail.com
Hello
I working on an bug With Xwin/Xorg and Solaris CDE WM which leads to
the freeze of the X server.
My research shows that this bug seems to be fixed in Xorg 1.8.99.905 (1.9
RC 5)
http://sourceware.org/bugzilla/show_bug.cgi?id=11301
[snip]
Fatal server error:
could not open default font 'fixed'
winDeinitMultiWindowWM - Noting shutdown in progress
I 've tried to follow the FAQ :
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof
but it didn't change anything
* The directories exist
* The fonts are at the good place (it's working with the Release:
1.8.2.0 (10802000))
perhaps i need to modify the fonts as I use a new version of the
libXfont package ?
Is someone can help me ?
Thanks,
Michel Hummel
http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=c482a2c104aa5cd1a265c2ca310a308dcc418fe7
Is the response to my question
Thanks
See also the section libXfont linkage issue in [1]. That documentation
needs to be updated to reflect the new reality once a libXfont is released
containing that change.
[1]
http://x.cygwin.com/docs/cg/prog-build-prerequisites.html#prog-compiling-environment-setup
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
Hello,
Thank you for your help.
Once this problem resolved, the server crashes with another message
(something like) :
--
assert failed (key-initialized); in privates.h
--
I've look in the header privates.h and deleted the assert test :
119 static inline void *
120 dixGetPrivateAddr(PrivatePtr *privates, const DevPrivateKey key)
121 {
122 // assert(key-initialized);
123 return (char *) (*privates) + key-offset;
124 }
Then the server seems to start and work correctly without any device problem.
Do you have an idea about this new and last issues ?
Thanks,
Michel Hummel
--
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/
RE: How to launch an xterm using Monospace font
Brian Timares wrote: Jean, I think this is what you want. I have: XTerm*font: -*-courier-medium-r-*-*-*-100-*-*-*-*-*-* in my .Xdefaults Other than colors, here is my .Xdefaults (in my home directory, natch): XTerm*scrollBar: on XTerm*saveLines: 9 XTerm*font: -*-courier-medium-r-*-*-*-140-*-*-*-*-*-* XTerm*visualBell: true XTerm*titeInhibit: true urxvt*secondaryScreen: false The most important part is the XTerm*titeInhibit: true, it is beyond me why that isn't the default everywhere (it prevents a screen clear when you're, say, done reading a man page). I want to get rid of the title bar but haven't explored that as I launch most of my xterms from a script. Extract: nohup xterm -name $h -title $h -ls -mc none +tb +mb -vb -sb -sl 9 -background grey95 -fg black -cr black -ms black -font -*-lucidatypewriter-medium-*-*-*-*-100-*-*-*-*-*-* -e ssh -Yq r...@$h /dev/null 21 Naturally $h is the server :) To get the fonts I launched xfontsel and went through it and experimented. Use the 'select' button to put the string into the buffer. Brian Thank you, Brian. It seems that full XLFD font name was necessary. Best regards. Jean Johner -- 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/
Re: Xorg/CDE bug, fixed in the last Xorg version 1.8.99.905
On 10/08/2010 09:26, Michel Hummel wrote: Thank you for your help. Once this problem resolved, the server crashes with another message (something like) : -- assert failed (key-initialized); in privates.h -- Then the server seems to start and work correctly without any device problem. Do you have an idea about this new and last issues ? You need the patch from [1] [1] http://lists.x.org/archives/xorg-devel/2010-August/011683.html 1.8.99.905 is a release candidate for the upcoming 1.9 release, you should expect minor issues like this if you choose to use it. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
Re: Right-click on text area freezes X server
Hi, This problem goot solved by using xorg-server 1.8.2-1. Point 2 (Slow response to keypresses in xorg-server-1.8.0-1) did not arise anymore, neither. Point 6 (frozen XDMCP session) is still there. Thanks for the excellent work. Rene - original message - Hi, This problem can easily be reproduced: - rlogin on a HP-UX 11.00 - start the wdb debugger (5.5.0) - right click on any text area field on it (e.g. source file or gdb command output) - X server hangs, meaning - the mouse cursor changes from a right2left arrow to a left2right one (and you can still move it around) - any type of mouse clicks have no effect (on any X Windows) - any keyboard input has no effect (including ESC) Killing the wdb (telnet from DOS + kill -9) unlocks the X server. The same happens when right clicking on any element in a xclearcase window (e.g. a file or a file version). Details: 1) I'm using a recent install of cygwin (July 2010) on XP Pro SP3 (bootcamped on a MacPro) 2) I downgraded xorg-server from 1.8.0-1 to 1.7.6-2 due to another bug (Slow response to keypresses in xorg-server-1.8.0-1, http://cygwin.com/ml/cygwin-xfree/2010-07/msg0.html). (I coulnd't find the mentioned 1.8.0-2 version in the cygwin setup, not even by selecting the experimental category) 3) I was going through the FAQs and mailing list and checked stuff like not having XAPPLRESDIR, XCMSDB, XNLSPATH and XKEYSYMDB defined. 4) I use the default Xserver startup shortcut (startxwin.exe), then start a local xterm and rlogin to the HP-UX. 5) No customization besides xterm menus in .XWinrc and xhost + in .startxwinrc 6) I get also a frozen X Server by left clicking twice on a drop-down menu (like the Personal Applications or Printer) in the CDE bottom bar on HP-UX 11.00 using XDMCP. This has already been reported as Bug 27295 - input freezes in XDMCP session with Solaris 10 CDE when interacting with panel (http://bugs.freedesktop.org/show_bug.cgi?id=27295). 7) I don't have any of the above three problems on a another machine using xorg-server 1.5.3-7. 8) These are offline machines (not connected to the Internet), so I can't use cygwin setup directly. 9) I'm using also SFU NFS client (installed only this package of the SFU suite). 10) Exceed is also installed (but not running at the same time of course) 11) cygcheck and XWin.o.log attached. Any help is deeply appreciated, thanks. Rene ursprüngliche Nachricht Ende -- 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/
RE: X hardware acceleration still flaky?
Right, thanks for gdb --pid= capture instructions in other mail; screengrabs of bt (if cygwin terminal supports copy and paste, I couldn't figure it out...)in private mail to you. Thanks for the right-click title-bar hint, Andy. And here's the backtrace text from Jon's XWin code drop at: ftp://cygwin.com/pub/cygwinx/XWin.20100808-git-66f3680cb47fbd09.exe.bz2 crashing after I place geomview's camera window on my second screen: Loaded symbols for /cygdrive/c/Windows/system32/msi.dll Reading symbols from /cygdrive/c/Windows/system32/SFC.DLL... warning: Lowest section in /cygdrive/c/Windows/system32/SFC.DLL is .text at 0040 1000 done. Loaded symbols for /cygdrive/c/Windows/system32/SFC.DLL Reading symbols from /cygdrive/c/Windows/system32/sfc_os.DLL...done. Loaded symbols for /cygdrive/c/Windows/system32/sfc_os.DLL [Switching to thread 5736.0x1a08] (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to thread 5736.0x16c4] 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll (gdb) bt #0 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #1 0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #2 0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll #3 0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367, width=450, height=450) at fbfill.c:48 #4 0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nrect=0, prect=0x1096791c) at fbfillrect.c:77 #5 0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nRects=1, pRects=0x10967914) at damage.c:1404 #6 0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at dispatch.c:1939 #7 0x0054c56e in Dispatch () at dispatch.c:439 #8 0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8) at main.c:286 (gdb) c Continuing. Program exited with code 0400. (gdb) cheers, L. SaVi satellite constellation visualization http://savi.sf.net/ -- 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/
Re: Unable to install X on 64-bit Windows 7 Premium
On 10/08/2010 00:19, Bob Kline wrote: I finally had to replace my ancient Windows XP box, and ended up with a Windows 7 Home Premium 64-bit system. If I run setup.exe to install a fresh cygwin, it succeeds as long as I don't touch the X11 set, leaving it at Default (which is to say, don't install anything in the set). If I change Default to Install for X11, I get a dialog box which says: Cygwin Setup - Running postinstall scripts Postinstall script errors The following errors occured executing postinstall scripts Package: gcc4-core gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. chmod 755 /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh and then run /etc/postinstall/gcc4-core.sh manually should work. I'm a bit surprised that gcc4 is a dependency of X. Package: libglade2.0_0 libglade2.0.sh exit code 2 Package: xinit xinit.sh exit code 8 Package: No package gcc4-core.sh exit code 126 libglade2.0.sh exit code 2 xinit.sh exit code 8 When I click Next, I get an error message saying the installation won't work properly unless I correct the failures which occurred, and tells me to look in the log file. The log file doesn't have anything beyond what appears in the dialog box as far as the errors are concerned, and there's no clue anywhere telling me how I'm supposed to go about correcting the errors. [snip] Could I please have some assistance figuring out how to correct the errors? What other information do I need to supply? Thanks for reporting these problems. Setup has only recently started recording problems with postinstall scripts, previously it would silently ignore failures. Hmm... it seems that the output from these failing commands is only captured in setup.log.full, not setup.log, so I think that messagebox needs fixing. You can look there, or run these scripts manually (they can be found in /etc/postinstall) and post the errors reported by those scripts so we can fix the problems. [1] http://sourceware.org/ml/cygwin/2010-08/msg00158.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
Bo nurkowanie jest fajne!
Klub Płetwonurków pisze: Czy jesteście Państwo zainteresowani otrzymaniem informacji handlowej, dotyczącej: 1. Nauki nurkowania 2. Turystyki rekreacyjno - nurkowej 3. Kursów nurkowych Jeżeli tak, prosimy o odesłanie zgody na dostanie informacji dotyczącej powyższych tematów na adres nadawcy. Niniejsze zapytanie nie jest informacją handlową, a jedynie zapytaniem o zgodę na przesyłanie informacji handlowych drogą elektroniczną, zgodnie z art. 10 ustawy z dnia 18 lipca 2002r. o świadczeniu usług drogą elektroniczną. (Dz.U. z 2002r. Nr 144, poz 1204 z późn. zm.) -- 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/
Re: Unable to install X on 64-bit Windows 7 Premium
On 8/10/2010 8:12 AM, Jon TURNEY wrote: gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. Thanks for your reply. I had seen that report, but was dismayed to see that the poster had received no response to his questions about whether the workaround really solved the problem or had just suppressed a symptom, leaving his system in a state which was causing subsequent installation actions (and other programs) to fail. Hmm... it seems that the output from these failing commands is only captured in setup.log.full, not setup.log, so I think that messagebox needs fixing. You can look there, or run these scripts manually (they can be found in /etc/postinstall) and post the errors reported by those scripts so we can fix the problems. I will (may take a few days, as we're about to take our daughter down to college). Thanks again. -- Bob Kline http://www.rksystems.com mailto:bkl...@rksystems.com -- 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/
Re: Unable to install X on 64-bit Windows 7 Premium
On 8/10/2010 11:16 AM, Jim Reisert AD1C wrote: Bob, FYI, I've been running Cygwin 1.7x and latest X on Win 7 Pro 64-bit and not problems setting up or running. In other words, it works right out of the box. Thanks for the data point, Jim. The two possible explanations that come to mind for the difference in results between your system and mine are (a) there's some difference in the way Win 7 Pro and Win 7 Premium behave which accounts for the failure on Premium; or (b) you installed at an earlier point in time, when something was different about the Cygwin packages or the Windows patches or both. I'm inclined to think (b) is more likely. Jon pointed out earlier in this thread that the visible reporting of postinstall failures is a recent change, so perhaps the installation failures occurred on your system as well, but the installer didn't bother to report them. I'll see what I can learn about theory (a) by experimenting with a virtual Win 7 Pro system. -- Bob Kline http://www.rksystems.com mailto:bkl...@rksystems.com -- 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/
Re: Unable to install X on 64-bit Windows 7 Premium
On 10/08/2010 13:12, Jon TURNEY wrote: On 10/08/2010 00:19, Bob Kline wrote: I finally had to replace my ancient Windows XP box, and ended up with a Windows 7 Home Premium 64-bit system. If I run setup.exe to install a fresh cygwin, it succeeds as long as I don't touch the X11 set, leaving it at Default (which is to say, don't install anything in the set). If I change Default to Install for X11, I get a dialog box which says: Cygwin Setup - Running postinstall scripts Postinstall script errors The following errors occured executing postinstall scripts Package: gcc4-core gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. chmod 755 /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh and then run /etc/postinstall/gcc4-core.sh manually should work. I'm a bit surprised that gcc4 is a dependency of X. Package: libglade2.0_0 libglade2.0.sh exit code 2 Package: xinit xinit.sh exit code 8 and since all xinit.sh does is run mkshortcut to create a start menu shortcut, I'd guess this is the same issue as [1], assuming we don't have a cygutils release with that fixed yet. [1] http://sourceware.org/ml/cygwin/2010-03/msg00357.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
Re: Unable to install X on 64-bit Windows 7 Premium
On 8/10/2010 11:49 AM, Jon TURNEY wrote: and since all xinit.sh does is run mkshortcut to create a start menu shortcut, I'd guess this is the same issue as [1], assuming we don't have a cygutils release with that fixed yet. [1] http://sourceware.org/ml/cygwin/2010-03/msg00357.html Right. As for the third problem (with libglade), the error output is add command failed could not open /etc/xml/catalog for saving Took a peek and saw that /etc/xml had not been created. So I created the directory and ran libglade2.0.sh again, reduced the error output to simply add command failed and when I checked for /etc/xml/catalog is saw that it had been created, but that it was empty. So I did some more googling, and found [1]. By adding --create to the script (and first removing the empty /etc/xml/catalog file) I was able to get the script to succeed. Unsettling that the libglade problem still hasn't been fixed after almost a couple of years, but at least I have (I think) fixed all three of the problems reported by the installer. As for the theories about the differences in results between Jim Reisert's Win 7 Pro machine and my Win 7 Premium box: I did the rest of my experimenting on a Win 7 Enterprise virtual machine, and ran into the same problems as on Win 7 Premium. So I'm pretty confident the different flavors of Win 7 had nothing to do with it. Much more likely that setup ran into the same failures (silently) on Win 7 Pro because the installation was done before setup was reporting the postinstall script failures. I would guess that the new practice of putting up the dialog window telling the new Cygwin user that his new installation will not work correctly until he fixes all of the errors which occurred will result in a decreased number of new users who are brave enough to persevere with Cygwin, but an increase in the number of problems which are actually reported and (let's hope) fixed. On balance, at least in the long run, a worthy trade-off. Thanks again for your assistance. [1] http://lists.macosforge.org/pipermail/macports-users/2008-October.txt -- Bob Kline http://www.rksystems.com mailto:bkl...@rksystems.com -- 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/
winsup/cygwin ChangeLog sigproc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-08-10 16:44:38 Modified files: cygwin : ChangeLog sigproc.cc Log message: * sigproc.cc (init_sig_pipe): Add retry loop. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4989r2=1.4990 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.326r2=1.327
src/winsup/utils ChangeLog mingw
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2010-08-10 22:01:55 Modified files: winsup/utils : ChangeLog mingw Log message: * mingw: Use sysroot, if present, for mingw_dir. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.534r2=1.535 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/mingw.diff?cvsroot=srcr1=1.6r2=1.7
Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Greetings, John Carey! After a call to SetCurrentDirectory(), I have seen occasional ( 5%) failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen failure of Cygwin signal handling because the signal handling pipe has mysteriously closed. Seems like it was discussed a short while ago. mid:008101cb3597$a75069f0$f5f13d...@gmail.com -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.08.2010, 12:56 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
Incomplete installation of subversion
Hi! I have a reasonably up to date cygwin installation (did an update a week ago or so). Today I run the latest setup (v2.708). In Pending I saw a few libX packages and minttty 0.8.1. Then I selected subversion for install. On Next I got a dialog saying that subversion depended on additional packages. I clicked... I don't really remember what, I guess it was OK or Yes. Then it installed subversion and the updates. But when I started mintty and entered svn, I got this: $ svn /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I started Setup again, and now under Pending I see: - wouldn't it be wonderful to be able to copy paste text from dialogs? - crypt - libgdm4 - libopenldap2_3_0 - libopenssl098 - libpq5 - libproxy0 - minires So what did I do wrong? I am waiting with the install of the above packages in case you have a question about the current state of my system. Regards, David -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Aug 10 00:19, John Carey wrote: After a call to SetCurrentDirectory(), I have seen occasional ( 5%) failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen failure of Cygwin signal handling because the signal handling pipe has mysteriously closed. Why on earth are you calling SetCurrentDirectory in a Cygwin application? I believe that both symptoms are due to this code in winsup/cygwin/path.cc, which as the comments state, is not thread-safe: /* Workaround a problem in Vista/Longhorn which fails in subsequent calls to CreateFile with ERROR_INVALID_HANDLE if the handle in CurrentDirectoryHandle changes without calling SetCurrentDirectory, and the filename given to CreateFile is a relative path. It looks like Vista stores a copy of the CWD handle in some other undocumented place. The NtClose/DuplicateHandle reuses the original handle for the copy of the new handle and the next CreateFile works. Note that this is not thread-safe (yet?) */ NtClose (*phdl); if (DuplicateHandle (GetCurrentProcess (), h, GetCurrentProcess (), phdl, 0, TRUE, DUPLICATE_SAME_ACCESS)) NtClose (h); you missed the else *phdl = h; If another thread allocates a handle between the NtClose and the Duplicate, then the handle value is not preserved, and strange effects may result. Note that phdl is a pointer to the handle storage within the PEB. Since the PEB is locked (RtlAcquirePebLock/RtlReleasePebLock) and Cygwin's cwdstuff::set as well as the native SetCurrentDirectory both lock the PEB before writing the CurDir content, there's no chance for a concurrency issue between those functions. Also note that the old content of *phdl is *always* overwritten, either by the result of the DuplicateHandle call, or by the value of CreateFile. Presumably the issues mentioned in the source comment may also occur, but what I have seen myself is a subsequent call to SetCurrentDirectory() closing, not the current directory handle, but the handle that was allocated by the other thread. Specifically, dll_crt0_1() calls sigproc_init(), then cwdstuff::set(), and finally wait_for_sigthread(). The function sigproc_init() creates the signal handling thread, which creates the signal handling pipe as one of its very first actions, then sets the event for which wait_for_sigthread() waits. I think this scenario happens: 1. main thread: cwdstuff::set(): NtClose(). 2. signal handling thread: CreatePipe() opens a handle to '\Device\NamedPipe\' and stores it in a global variable (because this is the first call to CreatePipe()). 3. main thread: cwdstuff::set(): DuplicateHandle(). In this case, the current directory handle value has changed, which is not the intend of the NtClose-Duplicate sequence. No, that's not intended. However, the code just *tries* to preserve the handle value, but it does not rely on it. The NtClose is safe because the handle is the actual CWD handle at the time of the call and the PEB is locked. The DuplicateHandle call just uses the phdl storage to store the new handle value, but it *never* tests if the new handle value is identical to the old one. So, if all works well, it's the same handle value as before. If not, *shrug*. CreateFile to fail with ERROR_INVALID_HANDLE as mentioned in the source comments, but I have not seen that. I think that the I have. You can easily test this as well on Vista and W7. Just drop the DuplicateHandle call and simply store h in *phdl. Then create a testcase: chdir (/); h = CreateFile (foobar, ...); if (h == INVALID_HANDLE_VALUE) printf (%lu\n, GetLastError()); CreatePipe() failures I have seen are triggered when SetCurrentDirectory() closes the handle to '\Device\NamedPipe\', thinking that it is the current directory handle. After that, CreatePipe() will fail with ERROR_INVALID_HANDLE. As mentioned above, calling SetCurrentDirectory in a Cygwin application is not correct at all. All relative path handling in Cygwin relies on the fact that a Cygwin application calls the chdir function. If you're calling SetCurrentDirectory you're on your own. And then again, note that the call to SetCurrentDirectory will not overwrite the PEB value of the cwd handle until the cwdstuff::set function has called RtlReleasePebLock. I think this other scenario also happens: 1. signal handling thread: CreatePipe() opens a handle to '\Device\NamedPipe\' (because it is the first call to CreatePipe()). 2. main thread: cwdstuff::set(): NtClose(). 3. signal handling thread: CreatePipe() opens pipe handles. 4. main thread: cwdstuff::set(): DuplicateHandle(). In this case it is Cygwin signal handling that is sabotaged by subsequent calls to SetCurrentDirectory(), because they close one of the pipe handles used for Cygwin signal handling. This is pure
Re: sed: --binary flag is undocumented
On Aug 9 16:41, Carles Cufi wrote: Hi there, I just found out in the IRC channel that to avoid trouble with cygwin's sed turning \r\n into \n one needs to pass the --binary flag. But this is not documented in the sed man pages, I was wondering if it should be. I think this is an upstream decision. You could ask the sed developers. 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: Incomplete installation of subversion
On 10 August 2010 12:41, David Balažic wrote: I have a reasonably up to date cygwin installation (did an update a week ago or so). Today I run the latest setup (v2.708). In Pending I saw a few libX packages and minttty 0.8.1. Then I selected subversion for install. On Next I got a dialog saying that subversion depended on additional packages. I clicked... I don't really remember what, I guess it was OK or Yes. Then it installed subversion and the updates. But when I started mintty and entered svn, I got this: $ svn /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I started Setup again, and now under Pending I see: - wouldn't it be wonderful to be able to copy paste text from dialogs? - crypt - libgdm4 - libopenldap2_3_0 - libopenssl098 - libpq5 - libproxy0 - minires So what did I do wrong? Nothing. It's a bug in the resolver behind the Unmet dependencies page: it doesn't add indirect dependencies. This is fixed in CVS, to be rolled out soon. I am waiting with the install of the above packages in case you have a question about the current state of my system. Thanks very much, but hopefully we've got this one cornered already. Andy -- 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: Fwd: BUG: ls generates faulty output from path with multiple spaces
On 08/10/2010 12:47 AM, James Arlow wrote: Too bad you don't have a WEB BASED BUG TRACKING SYSTEM, or you all wouldn't have gotten these two pointless emails To some degree, we have one: http://cygwin.com/ml/cygwin/ This mailing list IS our bug tracking system, and it DOES have a web archive. Meanwhile, no matter what system you set up on the web, I for one would still have the preferences set up to email me every change made in the web database. I work better on interrupts (such as email, whether it is sent directly by you or by the bot managing the web page) than on polling (randomly visiting the web page to see if someone has added a new bug since the last time I remembered to visit). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: Moses with Cygwin on Windows 7
I don't know if this might interest others, but I have found a thread explaining the UAC problem at http://social.answers.microsoft.com/Forums/en-US/vistasecurity/thread/67bfc4 b5-faff-4de4-be48-f395bf1c519d. There is an unofficial third-party software available from http://www.itknowledge24.com/ to create a white list so that specific programs can be exempted from UAC prompts. We don't have a computer with Windows 7 yet, so can't test it out, but I like the idea. Llio -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Eliot Moss Sent: 08 August 2010 00:34 To: cbs...@bangor.ac.uk Cc: l...@testun.co.uk; cygwin@cygwin.com Subject: Re: Moses with Cygwin on Windows 7 On 8/7/2010 5:23 PM, cbs...@bangor.ac.uk wrote: many thanks for your reply. On why we need cygwin: the language model we use is IRSTLM. The native windows build of Moses does not currently use IRSTLM LMs. I know next to nothing about Moses, so I'll just trust you on this one! I have been reading up a bit about debasing DLLs, and I gather from http://www.codeproject.com/KB/DLL/RebaseDll.aspx that the purpose is to avoid either two or more DLLs using the same preferred base addresses, or the overheads of relocation. However, on http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bac7e300-f3df -4087-9c4b-847880d625ad, it is suggested that from Vista onwards, it is better to leave this to the operating systems's ASLR (Address space layout randomization) in order to help defeat a ?return-to-libc? attack. Do you agree with this? If it is still necessary to do a rebase, what does your script do that rebaseall doesn't? The problem is that the address space randomization interferes with how cygwin support fork(). Suppose a parent process maps library A at address X, but does not map library B at all. Then suppose a forked process is not yet using library A, and ends up mapping library B at an address that overlaps X. Then the child reaches a point where it needs to use library A. The implementation of cygwin requires that if a parent and child use the same library, it must be at the same address. Therefore the child's mapping attempt will block. That gives a sense of the scenario. That may not be the exact case, but it's like that. Basically, we need to guarantee that all cygwin dlls map to different preferred places. Yes, this defeats the OS attempt to defeat a security attack. My script finds and rebases every dll file that cygwin 'find' can locate, while rebaseall only does certain directories. For me, the difference lies in (at least) some perl-related dlls that are not where rebaseall looks. Another important thing is that the distance between preferred locations needs to be a little bigger than the default for rebase, on Vista (and Windows 7). This is an obscure thing that Corinna found a while back and took me quite a while to locate in old email threads, but before I set that parameter, rebasing did not work right for me and after adding that it did. Maybe they have changed the default by now, but I don't think so. Re UAC prompts: this does look annoying but corporate security regulations may prevent us from turning it off completely. Is there some way to turn it off for individual programs without using third-party software? That lies outside my expertise. I just turned it off. Best wishes -- Eliot Moss -- 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
[ADMINISTRIVIA] Experimental block of some email with raw addresses
I've just instituted a block of email which contains certain email addresses like cygwin AT ..., cygwin-owner AT ... and others. Since I'm using spamassassin to do that, I suspect that the bounce message won't be really clear and it will increase my administrative burden but I thought I'd give it a try since it was relatively easy to do. 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
extending a VS python with cygwin
summary: I've got a version of python that I need for other purposes. I'm trying to build duplicity to use with that python. I'm getting m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py install ... error: Python was built with Visual Studio 2003; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing -c mingw32 to setup.py. How to do this? details: I mostly run linux, and I've been using python-based `duplicity` http://duplicity.nongnu.org/ to back that up. I've got an older winxp box (SP3, uptodate with WU) which I keep mostly to run ArcGIS, which has happily run many versions of cygwin (which I keep uptodate) over the years. I'd like to be able to restore my linux home to my cygwin home for the rare occasions when I need to use the winxp box. To do that, I'd like to install duplicity on the cygwin box. That install process (best described by the somewhat downlevel http://blog.khorun.com/2008/09/using-duplicity-on-windows-under-cygwin.html ) works for the install of the prerequisite GnuPGInterface and boto python modules (process=[download tarball, tar xfz, python setup.py install]) but fails for the install of duplicity itself, with the error: m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py install ... error: Python was built with Visual Studio 2003; Note that I'd cheerfully replace that version of python (the 2.5.2 that shipped with my ArcGIS 9.3), except that I use some ArcGIS extensions which seem to choke on other pythons :-( so I'd prefer to build against that if at all possible. extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing -c mingw32 to setup.py. I tried to take the advice offered, but fail: m...@cygwinbox ~/bin/duplicity-0.6.09$ python -c mingw32 setup.py install Traceback (most recent call last): File string, line 1, in module NameError: name 'mingw32' is not defined m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py -c mingw32 install usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option -c not recognized m...@cygwinbox ~/bin/duplicity-0.6.09$ python setup.py install -c mingw32 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: invalid command 'mingw32' What's the appropriate syntax here? Or how else should I fix this build problem? TIA, Tom Roche tom_ro...@pobox.com -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
Greetings to you as well! I did try to search, but was unsuccessful. Can you tell me the subject of one of the messages? Thanks, John Subject: Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set Greetings, John Carey! After a call to SetCurrentDirectory(), I have seen occasional ( 5%) failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen failure of Cygwin signal handling because the signal handling pipe has mysteriously closed. Seems like it was discussed a short while ago. mid:008101cb3597$a75069f0$f5f13d...@gmail.com -- WBR, Andrey Repin (anrdae...@freemail.ru) 10.08.2010, 12:56 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
Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2010 09:57, Andrey Repin wrote: Greetings, John Carey! After a call to SetCurrentDirectory(), I have seen occasional ( 5%) failures of CreatePipe() with code ERROR_INVALID_HANDLE. I have also seen failure of Cygwin signal handling because the signal handling pipe has mysteriously closed. Seems like it was discussed a short while ago. mid:008101cb3597$a75069f0$f5f13d...@gmail.com Out of interest, what is that strange email address above supposed to refer to? - -- Al -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxhqb8ACgkQz4fTOFL/EDYW1gCePOArKa9PB8qhvNwaeQgtGfTt v6cAn1ixv/R9+BvWnD7vSgxY2sSkj9t6 =DTsS -END PGP SIGNATURE- -- 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] Update on status of make-3.82 release for cygwin
I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like c:\foo in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. FYI. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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] Update on status of make-3.82 release for cygwin
On 8/10/2010 10:54 AM, Christopher Faylor wrote:
I wanted to let everyone know that I'm aware of the fact that make-3.82
has been released. However, given the number of reported problems in
the make bugs mailing list, I don't plan on releasing a new version of
GNU make until the dust has settled. That means no new version of make
for at least a month.
Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x,
I'm contemplating not doing what I'd previously mentioned - using new
changes in GNU make to allow MS-DOS file names like c:\foo in
makefiles. I'll have to investigate just how much the Windows-isms in
GNU make's code impact Cygwin make before I make a final determination.
I may just decide to reenable the --ms-dos option as it used to be in
the old days. Or, if that's too much work, I might just turn off
special-case handling of c:\blah entirely - just like it is in
make-3.81.
FYI.
Thanks for the heads up.
On Cygwin, make-3.82 supports DOS paths by default. I'm curious about
what work might be involved in re-enabling the --ms-dos option, and I'd
like to help, if I can.
I built my Cygwin make-3.82 packages directly from the upstream release
tarball using the attached script.
-Rob
#!/bin/bash
# naming convention and rules for generation from http://cygwin.com/setup.html
PACKAGE=make
VERSION=3.82
# release number
RELEASE=1
PACKAGE_BIN_FILE=${PACKAGE}-${VERSION}-${RELEASE}.tar.bz2
PACKAGE_SRC_FILE=${PACKAGE}-${VERSION}-${RELEASE}-src.tar.bz2
# constructed stuff
PACKAGE_BIN_DIR=usr
PACKAGE_SRC_DIR=${PACKAGE}-${VERSION}-${RELEASE}
# stuff for building
VENDOR_DIR=make-3.82
VENDOR_FILE=${VENDOR_DIR}.tar.gz
BUILD_PREFIX=/usr
# whack anything generated
rm -f -r ${PACKAGE_BIN_FILE} \
${PACKAGE_BIN_DIR} \
${PACKAGE_SRC_FILE} \
${PACKAGE_SRC_DIR} \
${VENDOR_DIR} \
|| exit 1
if [ $1 = clean ]
then
exit 0
fi
# unpack tarball
tar zxf ${VENDOR_FILE} || exit 1
# archive source for package
cp -r ${VENDOR_DIR} ${PACKAGE_SRC_DIR} || exit 1
# construct PACKAGE_SRC_FILE from archive
(tar cf - --owner=0 --group=0 ${PACKAGE_SRC_DIR} |
bzip2 ${PACKAGE_SRC_FILE}) || exit 1
if [ $1 = nobuild ]
then
exit 0
fi
pushd ${PACKAGE_SRC_DIR} || exit 1
# run ./configure
./configure --prefix=${BUILD_PREFIX} || exit 1
# note that make needs an absolute path for installation
make prefix=$(pwd)/../${PACKAGE_BIN_DIR} install || exit 1
popd
(tar cf - --owner=0 --group=0 ${PACKAGE_BIN_DIR} | \
bzip2 ${PACKAGE_BIN_FILE}) || exit 1
--
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] Update on status of make-3.82 release for cygwin
On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. -- 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] Update on status of make-3.82 release for cygwin
Am 10.08.2010, 19:54 Uhr, schrieb Christopher Faylor: I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like c:\foo in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. How about pointing people to mingw-make? I've been using that to build ntemacs for quite a while... -- Matthias Andree -- 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] Update on status of make-3.82 release for cygwin
On Tue, Aug 10, 2010 at 10:51:38PM +0200, Matthias Andree wrote: Am 10.08.2010, 19:54 Uhr, schrieb Christopher Faylor: I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like c:\foo in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. How about pointing people to mingw-make? I've been using that to build ntemacs for quite a while... http://cygwin.com/ml/cygwin-announce/2008-02/msg6.html -- 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] Update on status of make-3.82 release for cygwin
On 8/10/2010 1:21 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. Sorry for the confusion: I was not offering my script as hey look, here's how you do it, I was more saying I did it this way, but maybe that's too simple. What else is involved, and can I help with that? So: I'm still curious about the work you anticipate might be required. There's not much on the Cygwin site detailing the responsibilities of a package maintainer beyond: /Do you have the time to maintain the package?/ Packages without active maintainers are pulled from the distribution. Generally speaking the time commitment is relatively low, simply subscribe to the cygwin mailing list. We'd prefer if you read the non-digest mode since prompt response to packaging issues is a plus. When a /bug/ in your package is reported in the cygwin mailing list, address the bug (if it's a Cygwin-only bug) or pass back to the vendor. When a solution exists, create an updated package with the fix in it, and send a notification that you need the package uploaded to cygwin-apps. Note that you are not expected to be a helpdesk for the package - the users should be pointed to the vendors lists if you've determined that the bug is not a Cygwin-related bug. Thanks, Rob -- 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] Update on status of make-3.82 release for cygwin
On 8/10/2010 5:04 PM, Rob Walker wrote: On 8/10/2010 1:21 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. Sorry for the confusion: I was not offering my script as hey look, here's how you do it, I was more saying I did it this way, but maybe that's too simple. What else is involved, and can I help with that? So: I'm still curious about the work you anticipate might be required. There's not much on the Cygwin site detailing the responsibilities of a package maintainer beyond: It's a maintainer's responsibility to decide what's the best way to package the software for Cygwin. Obviously, there are basic guidelines, such as package naming, build scripts, and the like. But the rest is up to the maintainer. So if a maintainer doesn't think a feature fits well with Cygwin usage, then he/she is free to modify the package to disable that feature. Ditto if the feature is normally disabled but would be better enabled for Cygwin. This is the process that Chris is going through right now for make-3.82. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Aug 10 13:44 +0200 Corinna Vinschen wrote:
On Aug 10 00:19, John Carey wrote:
...
Presumably the issues mentioned in the source comment may
also occur, but what I have seen myself is a subsequent call to
SetCurrentDirectory() closing, not the current directory handle, but
the handle that was allocated by the other thread.
Specifically, dll_crt0_1() calls sigproc_init(), then cwdstuff::set(),
and finally wait_for_sigthread(). The function sigproc_init() creates
the signal handling thread, which creates the signal handling pipe as
one of its very first actions, then sets the event for which
wait_for_sigthread() waits. I think this scenario happens:
1. main thread: cwdstuff::set(): NtClose().
2. signal handling thread: CreatePipe() opens a handle to
'\Device\NamedPipe\' and stores it in a global variable (because
this is the first call to CreatePipe()).
3. main thread: cwdstuff::set(): DuplicateHandle().
In this case, the current directory handle value has changed, which is
not the intend of the NtClose-Duplicate sequence.
No, that's not intended. However, the code just *tries* to preserve the
handle value, but it does not rely on it. The NtClose is safe because
the handle is the actual CWD handle at the time of the call and the PEB
is locked. The DuplicateHandle call just uses the phdl storage to store
the new handle value, but it *never* tests if the new handle value is
identical to the old one. So, if all works well, it's the same handle
value as before. If not, *shrug*.
CreateFile to fail with ERROR_INVALID_HANDLE as mentioned in the
source comments, but I have not seen that. I think that the
I have. You can easily test this as well on Vista and W7. Just drop
the DuplicateHandle call and simply store h in *phdl. Then create a
testcase:
chdir (/);
h = CreateFile (foobar, ...);
if (h == INVALID_HANDLE_VALUE) printf (%lu\n, GetLastError());
Thanks for the test case for the CreateFile() problem; I used it to
create the following test, in which Windows 7 CreateFile() fails with
ERROR_INVALID_HANDLE even when using a stock Cygwin 1.7.5 DLL:
bu...@aeolus-w764c17 ~
$ uname -a
CYGWIN_NT-6.1-WOW64 aeolus-w764c17 1.7.5(0.225/5/3) 2010-04-12 19:07 i686
Cygwin
bu...@aeolus-w764c17 ~
$ cat test.c
#include windows.h
#include pthread.h
#include unistd.h
#include stdio.h
#include stdlib.h
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void * run (void *arg)
{
int count = (int)arg 1;
int sync = (int)arg 1;
while (count--) {
if (sync) pthread_mutex_lock(mutex);
HANDLE h = CreateFile (
foobar,
GENERIC_WRITE,
0,
NULL,
CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
INVALID_HANDLE_VALUE);
if (h == INVALID_HANDLE_VALUE) {
printf (%lu\n, GetLastError());
exit(1);
}
CloseHandle(h);
if (sync) pthread_mutex_unlock(mutex);
}
return 0;
}
int main (int argc, char** argv)
{
int count;
int sync;
pthread_t tid;
void *result;
if (argc != 2 argc != 3) {
fprintf(stderr, Usage: %s count [sync]\n, argv[0]);
return 2;
}
count = atol (argv[1]);
sync = argc = 3 ? !!atoi(argv[2]) : 0;
pthread_create (tid, 0, run, (void*)((count 1) | sync));
while (count--) {
if (sync) pthread_mutex_lock(mutex);
chdir (/);
if (sync) pthread_mutex_unlock(mutex);
}
pthread_join (tid, result);
return 0;
}
bu...@aeolus-w764c17 ~
$ gcc -o ~/test ~/test.c
bu...@aeolus-w764c17 ~
$ ~/test 1000 1
123
bu...@aeolus-w764c17 ~
$ ~/test 1000 0
123
bu...@aeolus-w764c17 ~
$ cd /
bu...@aeolus-w764c17 /
$ ~/test 1000 1
bu...@aeolus-w764c17 /
$ ~/test 1000 0
6
bu...@aeolus-w764c17 /
$
6 = The handle is invalid.:
I think that this is the error previously discussed.
Note that passing 1 as the second program argument
synchronizes the two threads and prevents the error.
123 = The filename, directory name, or volume label syntax is incorrect.:
I have not yet investigated why that error occurs, but it does
not happen if I run the test in the Cygwin root directory.
...
I think this other scenario also happens:
1. signal handling thread: CreatePipe() opens a handle to
'\Device\NamedPipe\' (because it is the first call to CreatePipe()).
2. main thread: cwdstuff::set(): NtClose().
3. signal handling thread: CreatePipe() opens pipe handles.
4. main thread: cwdstuff::set(): DuplicateHandle().
In this case it is Cygwin signal handling that is sabotaged by
subsequent calls to SetCurrentDirectory(), because they close one of
the pipe handles used for Cygwin signal handling.
This is pure speculation. Please explain to me how DuplicateHandle,
which duplicates a *local*
Missing APPDATA var in env of ssh sessions?
The mingw.org folks are developing a new installer, which uses WININET.dll facilities for d/l support. When I ran the application from within a cygwin shell, I ended up with the following debris in my testing /bin dir: $ pwd /c/msys-src/__xml/_test/bin $ ls libgcc_s_dw2-1.dll mingw-get.exe* $ ./mingw-get.exe update $ ls %APPDATA%/ libgcc_s_dw2-1.dll mingw-get.exe* $ find %APPDATA% %APPDATA% %APPDATA%/Microsoft %APPDATA%/Microsoft/Windows %APPDATA%/Microsoft/Windows/IETldCache %APPDATA%/Microsoft/Windows/IETldCache/index.dat Some googling indicates that this stuff is part of the network support provided by IE8 (or, the bits of Windows' networking that is provided by the DLLs associated with IE8). index.dat is a database for determining which domains are TLDs, and is user-customizable. If missing, it appears the IE8/WININET.dll/SHLWAPI.dll create it automatically. But the key is, it appears that the culprit, SHLWAPI.dll, checks the environment for %APPDATA% rather than using the MS-approved mechanism: SHGetSpecialFolderPath( 0, // Hwnd strPath, // String buffer. CSIDL_APPDATA, // CSLID of folder FALSE ); // Create if doesn't exists? $ strings /c/Windows/System32/SHLWAPI.dll | grep -i APPDATA %APPDATA% Now, a cmd box has this variable set: C:\Users\meecho %APPDATA% C:\Users\me\AppData\Roaming If I start a bash shell within that cmd box: C:\Users\mec:\cygwin-1.7\bin\bash --login the variable is still set: m...@computer[1.7] ~ $ echo $APPDATA C:\Users\me\AppData\Roaming The trick is, when I ssh in to the machine (even loopback), I don't have that env var: $ ssh localhost $ echo $APPDATA $ Now, this is a minor issue (does mingw-get work when invoked from a cygwin shell as part of a remote session?) However, I expect that the same flaw -- windows networking DLLs checking for %APPDATA% rather than using the Win32 API function -- would affect any native networking program that is launched from a cygwin remote session. Can ssh (or is it cygwin1.dll?) ensure that the user's APPDATA variable is populated, since it appears to be a pretty important var for Windows Vista+? -- Chuck -- 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 DLL 1.7.5-1 would not interfere with Symantec anti virus?
Hello. One of the issues fixed under the New Cygwin DLL 1.7.5-1 release is the memory leak. Does this mean that we wont have any problems ruuning anti virus software like Symantec anymore? -- 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] Update on status of make-3.82 release for cygwin
On Tue, Aug 10, 2010 at 02:04:47PM -0700, Rob Walker wrote: On 8/10/2010 1:21 PM, Christopher Faylor wrote: On Tue, Aug 10, 2010 at 01:13:41PM -0700, Rob Walker wrote: On Cygwin, make-3.82 supports DOS paths by default. I'm curious about what work might be involved in re-enabling the --ms-dos option, and I'd like to help, if I can. I built my Cygwin make-3.82 packages directly from the upstream release tarball using the attached script. I don't need help. I've been building make for years so I obviously don't need your script. Sorry for the confusion: I was not offering my script as hey look, here's how you do it, I was more saying I did it this way, but maybe that's too simple. What else is involved, and can I help with that? Once again: Don't need help. If you are thinking about maintaining a cygwin package then watch what is being discussed in cygwin-apps and read the Cygwin Packages link on the Cygwin web site. If you have a general question about cygwin packages then ask it. I'm not going to be providing you with my personal insights about make, however. 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Tue, Aug 10, 2010 at 09:53:46PM +, John Carey wrote: Thanks for the test case for the CreateFile() problem; I used it to create the following test, in which Windows 7 CreateFile() fails with ERROR_INVALID_HANDLE even when using a stock Cygwin 1.7.5 DLL: As Corinna said: If you are mixing Windows calls with cygwin calls you are far into unsupported territory. Cygwin isn't designed to let you seamlessly intermix things like pthreads/signals and the Windows API functions. If you can demonstrate a problem with pure Cygwin calls then go ahead and post a test case. Otherwise, I don't see this as an issue that needs to be addressed. 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
Update on status of make-3.82 release for cygwin
I wanted to let everyone know that I'm aware of the fact that make-3.82 has been released. However, given the number of reported problems in the make bugs mailing list, I don't plan on releasing a new version of GNU make until the dust has settled. That means no new version of make for at least a month. Also, given the ability to use more UNIX-like filenames in Cygwin 1.7.x, I'm contemplating not doing what I'd previously mentioned - using new changes in GNU make to allow MS-DOS file names like c:\foo in makefiles. I'll have to investigate just how much the Windows-isms in GNU make's code impact Cygwin make before I make a final determination. I may just decide to reenable the --ms-dos option as it used to be in the old days. Or, if that's too much work, I might just turn off special-case handling of c:\blah entirely - just like it is in make-3.81. FYI. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
