Re: ITP: autobuild
On Sep 19 15:58, Charles Wilson wrote: autobuild is a build-time requirement of the upcoming libtool-2.4 release (but not of packages that merely USE libtool, even if you autoreconf them). I'm not sure whether it is included in any linux distributions or not; I get too many hits when searching for 'autobuild'...so, I probably need some votes. However, given that it is a new build requirement of libtool, I imagine that the distros will be forced to add it eventually. ...which in turn means, this package is auto-approved. It's apparently not in distros yet, I only get hits for autobuild-applet, which is a different beast. Anyway, just go ahead. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITP: autobuild
Hi Chuck, Den 2010-09-19 21:58 skrev Charles Wilson: Autobuild is a package that process output from building software, primarily focused on packages using Autoconf and Automake, and then generate a HTML summary file, containing links to each build log. The output include project name, version, build host types (cross compile aware), compiler host name, date of build, and indication of success or failure. The output is indexed in many ways to simplify browsing. autobuild is a build-time requirement of the upcoming libtool-2.4 release (but not of packages that merely USE libtool, even if you autoreconf them). I'm not sure whether it is included in any linux distributions or not; I get too many hits when searching for 'autobuild'...so, I probably need some votes. However, given that it is a new build requirement of libtool, I imagine that the distros will be forced to add it eventually. But is it really a requirement? If you are referring to libtool commit v2.2.10-92-g92d24b3, then that patch adds an /optional/ dependency on autobuild. If you are a maintainer doing a release of libtool, it probably is a requirement, but are you not simply building the released version (perhaps with a few patches)? I know that I certainly have built git libtool many times when working on it, and I do not have autobuild installed. That said, +1 if votes are needed. Cheers, Peter
Re: ITP: autobuild
On 9/20/2010 4:15 AM, Peter Rosin wrote: But is it really a requirement? If you are referring to libtool commit v2.2.10-92-g92d24b3, then that patch adds an /optional/ dependency on autobuild. If you are a maintainer doing a release of libtool, it probably is a requirement, but are you not simply building the released version (perhaps with a few patches)? I know that I certainly have built git libtool many times when working on it, and I do not have autobuild installed. cygport -- unless overridden -- always runs 'autoreconf' on a package. autoreconf runs aclocal, which means autobuild.m4 must be available; hence, *the way we routinely (re)build libtool*, autobuild is required. Ironically, the main reason cygport autoreconf's everything is to ensure that libtoolized packages use cygwin's customized version of...libtool. -- Chuck
Re: ITP: autobuild
On 09/20/2010 08:24 AM, Charles Wilson wrote: On 9/20/2010 4:15 AM, Peter Rosin wrote: But is it really a requirement? If you are referring to libtool commit v2.2.10-92-g92d24b3, then that patch adds an /optional/ dependency on autobuild. If you are a maintainer doing a release of libtool, it probably is a requirement, but are you not simply building the released version (perhaps with a few patches)? I know that I certainly have built git libtool many times when working on it, and I do not have autobuild installed. cygport -- unless overridden -- always runs 'autoreconf' on a package. autoreconf runs aclocal, which means autobuild.m4 must be available; hence, *the way we routinely (re)build libtool*, autobuild is required. Ironically, the main reason cygport autoreconf's everything is to ensure that libtoolized packages use cygwin's customized version of...libtool. Yes, it is rather ironic that building the cygwin package of libtool requires running autoreconf, in order to use cygwin's libtool to fix up the build of cygwin's libtool. At any rate, +1 from me for packaging autobuild. There are several other GNU packages that use autobuild.m4 (such as coreutils and m4), but they include it in the tarball rather than expecting it to be pre-installed the way libtool 2.4 appears to be doing things. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: ITP: autobuild
On 9/20/2010 10:43 AM, Eric Blake wrote: Ironically, the main reason cygport autoreconf's everything is to ensure that libtoolized packages use cygwin's customized version of...libtool. Yes, it is rather ironic that building the cygwin package of libtool requires running autoreconf, in order to use cygwin's libtool to fix up the build of cygwin's libtool. Well, I could always create a tarball on *my* machine using 'make dist', such that (a) it would already have been bootstrapped with all the latest cygwin goodies, and (b) its aclocal would already contain the necessary info from autobuild.m4. Then the cygport(5) would be able to skip the autoreconf (actually, ./bootstrap) step on any *rebuilder's* machine...but I'd really rather not have to jump thru those hoops. And it would mean that *I* would have to have an unofficial package on my machine. It's better all around to consider autobuild a build-time requirement of libtool -- since although it is referred to as optional it really is required unless somebody (like me) jumps through those hoops I mentioned. At any rate, +1 from me for packaging autobuild. There are several other GNU packages that use autobuild.m4 (such as coreutils and m4), but they include it in the tarball rather than expecting it to be pre-installed the way libtool 2.4 appears to be doing things. It's not actually clear how 2.4 will be packaged, yet -- although we should find out within 24 hours. I really had wanted to get another version of libtool out to the cygwin community with the new lto support, for testing, BEFORE 2.4 was released, but I just didn't have the time. I guess we'll find out if the lto stuff works with cygwin-gcc-4.5.x after the libtool-2.4 release. :-( -- Chuck
Re: ITP: autobuild
On 09/20/2010 08:24 AM, Charles Wilson wrote: On 9/20/2010 4:15 AM, Peter Rosin wrote: But is it really a requirement? If you are referring to libtool commit v2.2.10-92-g92d24b3, then that patch adds an /optional/ dependency on autobuild. If you are a maintainer doing a release of libtool, it probably is a requirement, but are you not simply building the released version (perhaps with a few patches)? I know that I certainly have built git libtool many times when working on it, and I do not have autobuild installed. cygport -- unless overridden -- always runs 'autoreconf' on a package. autoreconf runs aclocal, which means autobuild.m4 must be available; hence, *the way we routinely (re)build libtool*, autobuild is required. No, if I understand Peter's comment correct, autobuild is NOT required for libtool, even with an autoreconf. Why? Because the original libtool patch at commit 92d24b3 made the use of AB_INIT optional - it only calls the macro _if_ autobuild.m4 could be found in the first place. When AB_INIT is not found, the only change is that the generated ./configure file no longer outputs magic strings that can be recognized by an autobuild daemon; missing strings merely makes it harder to submit build results to an autobuild daemon, but has no effect on how libtool itself behaves. Reduced configure output is not a build dependency; that would be the case only if the act of running autoreconf on libtool flat-out fails if autobuild was not present. Furthermore, I just sent a patch to libtool that avoids the need to have autobuild installed in the first place: http://thread.gmane.org/gmane.comp.gnu.libtool.general/11095/focus=10741 So, I still think that providing autobuild as a cygwin package makes sense, but since I'm arguing that it is NOT a build requirement for libtool, it means we need a previous distro link or the full 5 votes. We're at 2 now; anyone else want to chime in? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: ITP: autobuild
On 9/20/2010 2:22 PM, Eric Blake wrote: No, if I understand Peter's comment correct, autobuild is NOT required for libtool, even with an autoreconf. Why? Because the original libtool patch at commit 92d24b3 made the use of AB_INIT optional - it only calls the macro _if_ autobuild.m4 could be found in the first place. When AB_INIT is not found, the only change is that the generated ./configure file no longer outputs magic strings that can be recognized by an autobuild daemon; missing strings merely makes it harder to submit build results to an autobuild daemon, but has no effect on how libtool itself behaves. Reduced configure output is not a build dependency; that would be the case only if the act of running autoreconf on libtool flat-out fails if autobuild was not present. Ehh...okay. I was simply going the text in HACKING: * Make sure you have wget, xz, and autobuild installed. aclocal should be able to find autobuild.m4; or you can install it into the tree with aclocal -I libltdl/m4 --install There was also a short conversation between Ralf and Gary about the autobuild requirement but (a) I can't find it, and (b) I don't really remember the resolution. However, that's a non-issue now: Furthermore, I just sent a patch to libtool that avoids the need to have autobuild installed in the first place: http://thread.gmane.org/gmane.comp.gnu.libtool.general/11095/focus=10741 Right, I see that was approved and pushed, so... So, I still think that providing autobuild as a cygwin package makes sense, but since I'm arguing that it is NOT a build requirement for libtool, it means we need a previous distro link or the full 5 votes. We're at 2 now; anyone else want to chime in? Yep, now we actually need votes. -- Chuck
Re: ITP: autobuild
On Mon, Sep 20, 2010 at 04:31:34PM -0400, Charles Wilson wrote: Yep, now we actually need votes. +1 cgf
Re: Running Java application with drag and drop support in cygwin
Any update? On Wed, Dec 23, 2009 at 6:26 PM, Dees deepali.shef...@gmail.com wrote: People, any clue? Struggling really hard. On Fri, Dec 18, 2009 at 11:23 AM, Dees deepali.shef...@gmail.com wrote: Hi Jon, Did you get a chance to look at this? From whatever posts available online, I could not get a clue what is going wrong. Please respond. Thanks, Shefali On Mon, Dec 14, 2009 at 12:12 PM, Dees deepali.shef...@gmail.com wrote: On Fri, Nov 13, 2009 at 8:26 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 30/10/2009 09:06, Dees wrote: Your reply is much appreciated Jon. I will try to be more specific about the problem in further mails. On Thu, Oct 29, 2009 at 8:11 PM, Jon TURNEYjon.tur...@dronecode.org.uk wrote: On 28/10/2009 05:57, Dees wrote: I have developed a Java application involving jTree with extensive drag and drop support, which runs correctly in my Linux box. However, when I switch to a windows box and access the same Linux box using cygwin x-server, the drag and drop in jTree stops working. Interestingly, rest of the application still works fine. After analyzing a bit I found that x-server is able to recognize the drag event but fails to recognize a drop event. Details? OS : Suse Linux Enterprise Server 10 (i586) Version : 10 Patch level : 3 Other version information: Java : JDK 5 Cygwin setup-version: 2.573.2.3 Also tried using Xming 6.9.0.31 ssh same Linux setup from Windows, but that also doesn't solve the problem. Is there any setting, which should be done prior to running the Java swing applications? Here is a sample code which behaves in exactly same way. http://www.java2s.com/Code/Java/Swing-JFC/TreeDragandDrop.htm I have no idea how to use that java code to reproduce the problem you are seeing. Using the above java code in Linux: 1. Download and Install Java Development Toolkit on your Linux box (Java sun download site: http://java.sun.com/javase/downloads/index.jsp), if you do not have it already. 2. Save the sample code in the above link with the file name TreeTester.java, say in /home/user/ 3. Navigate to TreeTester.java from shell, and compile the java code: # cd /home/user/ # /usr/java/jdk1.5.0_14/bin/javac TreeTester.java Ignore any warnings of deprecated APIs. 4. This will create a few .class files in /home/user/ directory. Final step is to run the Java code, using: # /usr/java/jdk1.5.0_14/bin/java -classpath . TreeTester This will open up a GUI, with a jTree each on left and right pane. You can drag and drop any of the leaf nodes from one jTree to the root node of the other jTree and this should add a new node in the other jTree. You will get messages on console for the operations being performed. Now ssh the same box using cygwin/xming from any other windows box, and run the application using command in step 4. You should be able to drag (a small icon will come under cursor indicating that something is being dragged) but when you will drop it, the new node would not be added to the tree. Thats where lies my problem!!! Thanks for the test case and instructions, this makes it much easier for me to try it out. However, this testcase and your jar archive both work fine for me (using Xserver 1.7.1-3)! May be my problem is related to some setting. Though, not sure. Has anybody come across something similar? What should be done then? Please let me know. No it's probably a bug in Cygwin/X. But you're going to need to be a lot more specific about the problem before any progress can be made on fixing it. Also, putting some debug messages in the code lets me conclude that it's the drop event which is not being recognized, as the main control never reaches there. There is not really any drop event, as far as the X server is concerned, just mouse click and motion events, which are passed on to you application (which has a framework to interpret them as dragging and dropping an item). Now having a better idea of the problem, it seems less likely it is an Xserver bug at all. The only Xserver cause I can think of would be if it was somehow not sending the correct events to your applications window, which you could test using xev -id your applications window id (you can use xwininfo to find the window id) I have tried this, but could not get any idea if any event is going wrong. Here is the output of xev -id 0xe00021 (only for drag and drop event): LeaveNotify event, serial 13, synthetic NO, window 0xe00021, root 0x5a, subw 0xe00025, time 3560250, (87,65), root:(91,95), mode NotifyGrab, detail NotifyVirtual, same_screen YES, focus YES, state 256 FocusOut event, serial 13, synthetic NO, window 0xe00021, mode NotifyGrab, detail NotifyAncestor EnterNotify event, serial 13, synthetic NO, window 0xe00021,
Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
On 18/09/2010 19:44, michel hummel wrote: I have checked the code of the clipboard thread and the race condition you talk about should not be a problem. Before to start a new clipboard thread, the code waits for the end of the first thread (pthread_join) then fixe the variable g_fClipboardLaunched = FALSE; g_fClipboardStarted = FALSE; So the new thread will never be launched before the old one has terminated. I have a proposition of modification to make the clipboard thread more robust. 1/ Adding a cleanup function which will be automaticaly called at the end of the thread. I purpose the use of the macro pthread_cleanup_push() pthread_cleanup_pop() 2/ You said that having a long-lived thread will be a good solution to simplify the code. I have an other proposition which needs less modification and can simplify the code : By using also here the macro pthread_cleanup_push() we can automaticaly restart the thread on every unexpected exit. We just have to delete this restart when the exit is expected (ie. End of the function) With this solution we don't have to take care about the thread being killed by anyone, it will be restarted. You will need to have some kind of back-off mechanism (i.e. a delay before retrying to connect) so that that this doesn't constantly try to connect if the server gets into a state where it can't accept the connection or the connection is constantly getting closed. 3/ An other thing I saw is that when the Xwindow part of the clipboard is killed by an other application, the thread will still be alive but the clipboard doesn't work anymore. A solution can be : when an winClipboardErrorHandler() is catched, check for this Xwindow window and whenever this window doesn't exist anymore, create a new one. Would it not be simpler to restart the clipboard thread in this situation as well, rather than having code to recrate the window? What do you think about my suggestions ? I tested them and they seem to work as expected. For example, I skipped the wrapper of XQueryTree (actualy needed for xdmcp) and the clipboard is now working with xdmcp/gdm, etc. If you don't like something in my propositions, please tell me what and I will try to adapt it. If you are interested in a patch doing this, I will be happy to give it after a quick review and a clean That would be great, thank you. -- 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: CygwinX at MS Terminalserver?
On 27/08/2010 16:52, Jon TURNEY wrote: On 16/08/2010 07:35, Steffen Sledz wrote: Am 13.08.2010 13:09, schrieb Jon TURNEY: Now testuser0002 tries to start another server in parallel. This gives this error: /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0 This is expected. As I said, each X server instance must have a unique display number. This can't possibly work any other way. If two users both have an X server with display number 0, to which server should a client started with DISPLAY=:0.0 connect? That's clear. I thought (or hoped) that starting X server using the XWin Server menu item automatically searches for an unused display number and uses it. I think that would be a good default behaviour. I agree it would be useful, and it is on the todo list [1], but there's a non-trivial problem to solve first: How is the display number which the server has allocated communicated to other processes, so that the users clients appear on the right display? The fedora -displayfd patch seems to have moved and now lives at [1] I've built an Xserver including an updated and modified version of this patch and uploaded it at [2]. Perhaps you could give that a try and see if it works for your purposes? -displayfd fd specifies a file descriptor in the launching process. Rather than specify a display number, the X server will attempt to listen on successively higher display numbers, and upon finding a free one, will write the display number back on this file descriptor as a newline-terminated string. The -pn option is ignored when using -displayfd. If you start the X server first and then launch everything from the traymenu, everything would works fine, as the X server places a correct DISPLAY variable into the environment inherited by the child process. But if you start the X server via xinit/startx/startxwin, the display number needs to be communicated back to xinit, so that the correct display number is used for clients which are subsequently started by xinit. I've also patched xinit/startxwin so they transparently handle the -displayfd X server option, uploaded at [3],[4]. They handle the -displayfd option specially to modify the fd number passed to the Xserver so they can read it's output and set the display number correctly for clients which xinit/startxwin starts, then write that display number to the originally specified fd. (Patch to follow. Note that this patch probably won't apply to a stock xinit-1.2.1 as it's based on top of the patch which adds startxwin) Fedora ships with a patch [2] which adds the -displayfd option, which allocates a display number and writes it to the specified fd. But to be useful to us, xinit would needs some code to use that flag (under some circumstances) and read that display number and use it for the clients it creates. There's also the case where the user explicitly sets DISPLAY programmatically or manually before starting clients. I think with some suitable shell scripting, -displayfd probably can be used for that also. Something along the lines of adding '-displayfd 3 3~/.display' to the Xserver invocation, and then 'export DISPLAY=:`cat ~/.display`' to ~/.bashrc might be sufficient. [1] http://x.cygwin.com/devel/todo.html [2] http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-displayfd.patch [1] http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=tree [2] ftp://cygwin.com/pub/cygwinx/XWin.20100916-git-df5773ea3927d9c1.exe.bz2 [3] ftp://cygwin.com/pub/cygwinx/startxwin.exe [4] ftp://cygwin.com/pub/cygwinx/xinit.exe -- 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/
[PATCH] os: Add -displayfd option.
This option specifies a file descriptor in the launching process. X
will scan for an available display number and write that number back to
the launching process, at the same time as SIGUSR1 generation. This
means display managers don't need to guess at available display numbers.
As a consequence, if X fails to start when using -displayfd, it's not
because the display was in use, so there's no point in retrying the X
launch on a higher display number.
Signed-off-by: Adam Jackson a...@redhat.com
Update for current X server
Fix null DISPLAY crash when stderr is closed
Rearrange init order to avoid null DISPLAY crash and correctly use
DISPLAY in default logfile name when logfile isn't specified on command line
Don't put '\'n on end of DISPLAY so internal XWin uses work correctly
Do a bit more logging about what we are trying to do
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
dix/globals.c|1 +
dix/main.c |7 +++-
doc/Xserver.man.pre |7
hw/xwin/InitOutput.c | 10 +++---
include/opaque.h |1 +
os/connection.c | 75 ++---
os/osinit.c |4 +-
os/utils.c | 11 +++
8 files changed, 84 insertions(+), 32 deletions(-)
diff --git a/dix/globals.c b/dix/globals.c
index c24a94f..19168f4 100644
--- a/dix/globals.c
+++ b/dix/globals.c
@@ -134,6 +134,7 @@ int defaultColorVisualClass = -1;
int monitorResolution = 0;
char *display;
+int displayfd;
char *ConnectionInfo;
CARD32 TimeOutValue = DEFAULT_TIMEOUT * MILLI_PER_SECOND;
diff --git a/dix/main.c b/dix/main.c
index f023536..4e0ec93 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -168,8 +168,7 @@ int main(int argc, char *argv[], char *envp[])
DPMSPowerLevel = 0;
#endif
InitBlockAndWakeupHandlers();
- /* Perform any operating system dependent initializations you'd like */
- OsInit();
+
if(serverGeneration == 1)
{
CreateWellKnownSockets();
@@ -183,6 +182,10 @@ int main(int argc, char *argv[], char *envp[])
}
else
ResetWellKnownSockets ();
+
+ /* Perform any operating system dependent initializations you'd like */
+ OsInit();
+
clients[0] = serverClient;
currentMaxClients = 1;
diff --git a/doc/Xserver.man.pre b/doc/Xserver.man.pre
index ce3b3a1..a6bd906 100644
--- a/doc/Xserver.man.pre
+++ b/doc/Xserver.man.pre
@@ -121,6 +121,13 @@ Not obeyed by all servers.
.B \-core
causes the server to generate a core dump on fatal errors.
.TP 8
+.B \-displayfd \fIfd\fP
+specifies a file descriptor in the launching process. Rather than specify
+a display number, the X server will attempt to listen on successively higher
+display numbers, and upon finding a free one, will write the display number
back
+on this file descriptor as a newline-terminated string. The \-pn option is
+ignored when using \-displayfd.
+.TP 8
.B \-deferglyphs \fIwhichfonts\fP
specifies the types of fonts for which the server should attempt to use
deferred glyph loading. \fIwhichfonts\fP can be all (all fonts),
diff --git a/hw/xwin/InitOutput.c b/hw/xwin/InitOutput.c
index b144136..295c010 100644
--- a/hw/xwin/InitOutput.c
+++ b/hw/xwin/InitOutput.c
@@ -700,13 +700,13 @@ OsVendorInit (void)
if (!g_fLogInited) {
/* keep this order. If LogInit fails it calls Abort which then calls
- * ddxGiveUp where LogInit is called again and creates an infinite
- * recursion. If we set g_fLogInited to TRUE before the init we
- * avoid the second call
- */
+ * ddxGiveUp where LogInit is called again and creates an infinite
+ * recursion. If we set g_fLogInited to TRUE before the init we
+ * avoid the second call
+ */
g_fLogInited = TRUE;
g_pszLogFile = LogInit (g_pszLogFile, NULL);
- }
+ }
LogSetParameter (XLOG_FLUSH, 1);
LogSetParameter (XLOG_VERBOSITY, g_iLogVerbose);
LogSetParameter (XLOG_FILE_VERBOSITY, g_iLogVerbose);
diff --git a/include/opaque.h b/include/opaque.h
index b3c7c70..ea0ac13 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -50,6 +50,7 @@ extern _X_EXPORT int ScreenSaverAllowExposures;
extern _X_EXPORT int defaultScreenSaverBlanking;
extern _X_EXPORT int defaultScreenSaverAllowExposures;
extern _X_EXPORT char *display;
+extern _X_EXPORT int displayfd;
extern _X_EXPORT int defaultBackingStore;
extern _X_EXPORT Bool disableBackingStore;
diff --git a/os/connection.c b/os/connection.c
index 85d0d10..9712729 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -146,6 +146,7 @@ Bool NewOutputPending; /* not yet attempted to
write some new output */
Bool AnyClientsWriteBlocked; /* true if some client blocked on write */
static Bool RunFromSmartParent;/* send SIGUSR1 to parent process */
+static char dynamic_display[7];
Bool PartialNetwork; /* continue even if unable to bind all addrs */
static Pid_t ParentProcess;
@@ -374,9 +375,25 @@
[PATCH] Handle X server -displayfd option transparently
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
xinit.c | 68 +++---
1 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/xinit.c b/xinit.c
index 918f83e..95ba13c 100644
--- a/xinit.c
+++ b/xinit.c
@@ -168,6 +168,11 @@ int serverpid = -1;
int clientpid = -1;
volatile int gotSignal = 0;
+static int original_displayfd = -1;
+static int server_displayfd_read = -1;
+static char server_displayfd_write[256];
+static char displayfd_buf[256];
+
static void Execute ( char **vec, char **envp );
static Bool waitforserver ( void );
static Bool processTimeout ( int timeout, char *string );
@@ -319,14 +324,40 @@ main(int argc, char *argv[], char *envp[])
}
if (argc 0 (argv[0][0] == ':' isdigit(argv[0][1])))
displayNum = *argv;
- else
- displayNum = *sptr++ = default_display;
start_of_server_args = (sptr - server);
while (--argc = 0) {
+ /* Handle the -displayfd server argument transparently */
+ if ((argc 0) (strcmp(argv[0],-displayfd) == 0))
+ {
+int filedes[2];
+
+original_displayfd = atoi(argv[1]);
+
+if (pipe(filedes) == 0)
+ {
+server_displayfd_read = filedes[0];
+sprintf(server_displayfd_write, %d, filedes[1]);
+argv[1] = server_displayfd_write;
+ }
+else
+ {
+Fatal(pipe() for -displayfd failed);
+ }
+ }
+
server_args_given++;
*sptr++ = *argv++;
}
+
+/*
+ if there was neither an explicit displayNum nor a
+ -displayfd option, add the default display number
+ to server arguments
+*/
+if ((displayNum == NULL) (original_displayfd == -1))
+ displayNum = *sptr++ = default_display;
+
#ifdef STARTXWIN
*sptr++ = -multiwindow;
#endif
@@ -391,11 +422,6 @@ main(int argc, char *argv[], char *envp[])
#endif
/*
-* put the display name into the environment
-*/
- set_environment ();
-
- /*
* Start the server and client.
*/
#ifdef SIGCHLD
@@ -423,7 +449,7 @@ main(int argc, char *argv[], char *envp[])
#endif
#endif
- if (XOpenDisplay(displayNum)) {
+ if (displayNum XOpenDisplay(displayNum)) {
Error(Another X server instance is running on DISPLAY %s\r\n,
displayNum);
exit(ERR_EXIT);
}
@@ -487,6 +513,32 @@ waitforserver(void)
sleep(2);
#endif
+if (server_displayfd_read != -1)
+ {
+/* wait for the server to write the DISPLAY number to the
displayfd pipe */
+int length;
+
+displayfd_buf[0] = ':';
+length = read(server_displayfd_read, displayfd_buf+1, 255);
+
+if (length 0)
+ Fatal(reading displayfd pipe failed);
+displayfd_buf[length] = '\0';
+
+printf(read display number '%s' from X server\n, displayfd_buf);
+displayNum = displayfd_buf;
+
+/* write the DISPLAY received from the server to the original
displayfd */
+/* XXX: this should happen after connections are being accepted */
+write(original_displayfd, displayfd_buf+1, length);
+write(original_displayfd, \n, 1);
+ }
+
+ /*
+* put the display name into the environment
+*/
+ set_environment ();
+
for (cycles = 0; cycles ncycles; cycles++) {
if ((xd = XOpenDisplay(displayNum))) {
return(TRUE);
--
1.7.1
--
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: XWin crash after the launch of startkde on a remote Red Hat 5 machine
2010/9/20 Jon TURNEY jon.tur...@dronecode.org.uk: On 18/09/2010 19:44, michel hummel wrote: I have checked the code of the clipboard thread and the race condition you talk about should not be a problem. Before to start a new clipboard thread, the code waits for the end of the first thread (pthread_join) then fixe the variable g_fClipboardLaunched = FALSE; g_fClipboardStarted = FALSE; So the new thread will never be launched before the old one has terminated. I have a proposition of modification to make the clipboard thread more robust. 1/ Adding a cleanup function which will be automaticaly called at the end of the thread. I purpose the use of the macro pthread_cleanup_push() pthread_cleanup_pop() 2/ You said that having a long-lived thread will be a good solution to simplify the code. I have an other proposition which needs less modification and can simplify the code : By using also here the macro pthread_cleanup_push() we can automaticaly restart the thread on every unexpected exit. We just have to delete this restart when the exit is expected (ie. End of the function) With this solution we don't have to take care about the thread being killed by anyone, it will be restarted. You will need to have some kind of back-off mechanism (i.e. a delay before retrying to connect) so that that this doesn't constantly try to connect if the server gets into a state where it can't accept the connection or the connection is constantly getting closed. Like I’ve implemented it : - The clipboard thread uses the winProcEstablishConnection wrapper to restart and so it’s waiting for a new client connection before trying to reconnect himself. - An other point, the restart mechanism will only be activated if the clipboard thread has successfully been connected, otherwise the clipboard thread will dies and not restarts (this will prevent an infinite loop on connection error) Those two mechanisms and the loop on XOpenDisplay with the sleep (WIN_CONNECT_DELAY) between each retries should do the job isn't it ? But if you think a connection delay is also needed in the restart process can add one without problem 3/ An other thing I saw is that when the Xwindow part of the clipboard is killed by an other application, the thread will still be alive but the clipboard doesn't work anymore. A solution can be : when an winClipboardErrorHandler() is catched, check for this Xwindow window and whenever this window doesn't exist anymore, create a new one. Would it not be simpler to restart the clipboard thread in this situation as well, rather than having code to recrate the window? You are absolutely right, I just have to replace the window creation with a pthread_exit(NULL); What do you think about my suggestions ? I tested them and they seem to work as expected. For example, I skipped the wrapper of XQueryTree (actualy needed for xdmcp) and the clipboard is now working with xdmcp/gdm, etc. If you don't like something in my propositions, please tell me what and I will try to adapt it. If you are interested in a patch doing this, I will be happy to give it after a quick review and a clean That would be great, thank you. -- 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/
Problems using XWin with remote desktop with latest version
I have the following batch file to start xwin: @echo off SET CYGWIN_ROOT= SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% SET XAPPLRESDIR= SET XCMSDB= SET XKEYSYMDB= SET XNLSPATH= %RUN% XWin -multiwindow -clipboard -silent-dup-error IF EXIST %CYGWIN_ROOT%\bin\urxvtd-X.exe %RUN% %CYGWIN_ROOT%\bin\urxvtd-X.exe This works fine (and has been for a while year). Occasionally, I have to connect to my machine via windows remote desktop. I've also been doing this for a while. With the latest version of x-windows; however, when I do so XWin.exe seg faults. I then kill the urxvtd-X.exe process, re-run my batch script, and all is well within the remote desktop session. Then I close the remote desktop session, and when I get back to my machine the x-windows-based command windows are no longer functional. I close down Xwin.exe (and urxvtd-X.exe), restart them, and I'm ok again. Any ideas as to what has changed to cause these new issues, (a) XWin.exe seg fault due to remote desktop connection (sorry, I don't have the seg fault info) (b) X-windows based command windows, (i.e., windows started with: urxvtc -g 80x42 -e /bin/bash -l -i) no longer display correctly when I disconnect the remote desktop session - I have to 're-start' xwin.exe (and urxvtd-X.exe) processes. -- 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 fhandler_tty.cc signal ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-09-20 22:28:57 Modified files: cygwin : ChangeLog fhandler_tty.cc signal.cc spawn.cc cygwin/include/sys: cygwin.h Log message: * include/sys/cygwin.h (PID_NOTCYGWIN): New enum. * spawn.cc (spawn_guts): Set a flag when a process is not a cygwin process. * fhandler_tty.cc (fhandler_tty_slave::init): Remove previous change. Try a different method to determine when we should become the process group owner. * signal.cc (kill0): Remove archaic code which dealt with never-set flag. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5046r2=1.5047 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=uberbaumr1=1.206r2=1.207 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/signal.cc.diff?cvsroot=uberbaumr1=1.90r2=1.91 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/spawn.cc.diff?cvsroot=uberbaumr1=1.294r2=1.295 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/cygwin.h.diff?cvsroot=uberbaumr1=1.91r2=1.92
Re: Problems with gitk after cygwin update
On Sep 19 23:04, Michael Lutz wrote: Hello, I just updated my Cygwin installation with the newest packages, especially cygwin base from 1.7.5 to 1.7.7 and git from 1.7.1 to 1.7.2.3. I'm now having problems when I launch gitk in the background from a xterm, i.e. gitk . First of all, if I press any key after I switch back to the xterm, it just closes. On the prompt logout is visible for just a moment before it closes. Secondly, I got the following error log when clicking around in gitk to view some commits. I never had such problems before I updated. Michael Lutz --- snip 1 $ cygcheck -c cygwin git gitk Cygwin Package Information Package VersionStatus cygwin 1.7.7-1OK git 1.7.2.3-1 OK gitk 1.7.2.3-1 OK Windows 7 Pro x64 with all updates. --- snip 2 0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't initialize fd 0 for /dev/tty1 Stack trace: Frame Function Args 002838C8 6102749B (002838C8, , , ) 00283BB8 6102749B (61177B80, 8000, , 61179977) 00284BE8 61004AFB (611A1670, , 6123AAC4, 0001) End of stack trace 0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't initialize fd 0 for /dev/tty1 I can't reproduce the stack dumps, but I can reproduce the premature exit of the parent shell. This is a problem I'm still mulling over: http://cygwin.com/ml/cygwin/2010-09/msg00237.html Your scenario is equivalent since gitk uses the tk shell wish, which starts its child processes like a native Windows application using the CreateProcess call, rather than Cygwin's fork/exec. This in turn leads to a collision in the terminal foreground process group handling between the child process started by wish, and the parent bash. I have a simple solution for this problem, which is to revert the code in Cygwin to the 1.7.5 state. However, this isn't a satisfying solution, because this results in another problem: Microsoft Windows [Version 6.1.7600] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\cygwin\binset CYGWIN=tty C:\cygwin\binbash --login cori...@vmbert7 ~ $ cmd Microsoft Windows [Version 6.1.7600] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\cygwin\home\corinnabash --login== HANGS taking 100% CPU!!! I'd rather find a fix for both problems... 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: where was mention of what creates NUL files?
On 17.09.2010 20:12, Daniel Barclay wrote: Does anyone recall a mention of what in CygWin (or possibly Emacs) creates files with a simple name of NUL? I also use native Emacs and after some operation I got file with name NUL. I have a lot NUL files in many dirs, which can be removed only from Cygwin: $ rm NUL I don't fully debug but think this come from 'null-device' variable (which has 'NUL' value by default). To friend native GNU Emacs with Cygwin (and stop creating NUL) I use: (when (eq system-type 'windows-nt) (setq shell-file-name bash) ;; Workaround for Cygwin shell, when set 'CYGWIN=noglob'. By default 'shell-quote-argument' ;; quoted by double '\' chars this cause failure. (defun shell-quote-argument (argument) (concat ' argument ') ) ;; Workaround for Cygwin when 'shell-file-name' is 'bash'. (setq null-device /dev/null) ) -- Happy hacking! -- 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 from linux to cygwin + CUI + Ctrl-C
On Fri, Sep 17, 2010 at 7:58 AM, Andrew DeFaria and...@defaria.com wrote: On 09/16/2010 12:05 PM, Ilia K. wrote: Have you tried to ssh to cygwin, then run cmd.exe (to get a dos prompt) and then press Ctrl-C? Good lord man! Why would I want to do that?!? In my case this terminates cmd.exe and returns to bash, but this behavior is wrong (try to press Ctrl-C in cmd.exe which is run directly from the desktop, not from ssh session). Stop using cmd. cmd is just an example of native CUI windows program. Right now I actually need to run cdb, which is quite different app. -- 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: simplifying rebaseall
I'd beg to differ; I'd suggest it is, as suggested by the OP, actually quite a common use. You only have to look at the use of say perl and you will have users quite regularly compiling their own DLL's as they install modules via CPAN, and this is quite painful due to all the issues it can present with rebase. While I love cygwin, I must say that its supporting community can be very dismissive of its users to the point of alienating potential contributors. I myself has have experienced this on several occasions and have ended up finding myself not raising issues that affect us daily for fear of being shot down for no more reason that someone doesn't think its import to fix or should work that way anyway or even doesn't like the way you structured you post. To reiterate I still think that developers deserve much respect and thanks for all the effort they put in, but a little more open mindedness and approachability like that which can be found in other open source communities such as SFU and FreeBSD wouldn't go a miss sometimes ;-) Regards Steve thanks -- 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] Testing: mintty-0.9b1-1
On 18.09.2010 13:35, Andy Koppe wrote: CHANGES Colours: - Added ability to set the 16 ANSI colours in the config file (or on the command line via the -o option), like so: 'Blue=0,0,255' or 'BoldGreen=128,255,128'. The manual has all the colour names. This is very useful. Thanks. -- 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 from linux to cygwin + CUI + Ctrl-C
It looks like my reply got lost in mailer's spam filters, reposting. On Wed, Sep 15, 2010 at 5:36 PM, Christopher Faylor wrote: ... Cygwin summarily halts a pure-Windows process on receiving a CTRL-C. There is no way around that other than to relink the program to use Cygwin. Do you state that there is absolutely no way to make it work as I need? This would be very pity... Do you know what's the difference between running bash from sshd and from the desktop? In the later case, Ctrl-C works as expected! To me it looks like cygwin knows how to pass Ctrl-C to native apps, but sshd somehow interferes with it. Regards, Ilia. -- 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: Problems with gitk after cygwin update
Hello, thanks for looking into this. Am 20.09.2010 10:55 schrieb Corinna Vinschen: I can't reproduce the stack dumps, but I can reproduce the premature exit of the parent shell. This is a problem I'm still mulling over: http://cygwin.com/ml/cygwin/2010-09/msg00237.html I don't always get the stack dump either and I couldn't figure out a pattern for when it happens, so I'm not surprised. I can always open up a second xterm so this bug isn't that critical. There is another problem with git that I occasionally saw with older cygwin version as well, but feels to have become much more common lately. It happens when using git gui, which incidentally is a tk wish app as well. It's harder to reproduce, but the recipe below should do the trick. As a preparation in some temp dir: $ git init . $ echo -e a\nb file.txt $ git add file.txt $ git commit -m Commit $ echo -e a\na\nc\nd file.txt Now start citool: $ git gui citool The big pane on the right has some red and green line, click on one of these lines with a right click and select Stage this line. If you're lucky, this will hang git gui because it seems to wait for the output of a git command it spawned. The git command is hanging in process startup though, the stack trace below made with Process Explorer of the hanging command looks like it is waiting on some mutex. If it actually works the first try, click on the file icon in the lower left pane to unstage the line again and repeat until the hang occurs. It happens quite often that it hangs the first time for me, but sometimes it only hangs after several minutes of work done with git gui. Michael Lutz --- snip 1 --- Stack trace with Process Monitor Command C:\cygwin\lib\git-core\git-rev-parse.exe --verify HEAD ntoskrnl.exe!SeAccessCheckWithHint+0xb4a ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2 ntoskrnl.exe!KeWaitForMutexObject+0x19f ntoskrnl.exe!PsIsSystemProcess+0x94 ntoskrnl.exe!KeStackAttachProcess+0x11c1 ntoskrnl.exe!ObReferenceObjectByPointerWithTag+0x233 ntoskrnl.exe!PsLookupProcessThreadByCid+0x56f ntoskrnl.exe!KeTestAlertThread+0xa79 ntoskrnl.exe!KeTestAlertThread+0x9fb ntdll.dll!RtlUserThreadStart -- 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: Windows Server 2008 64-bit setup.exe/bash problem - Amazon Cloud
Hey, great find, I'm glad to know that this wasn't all me being crazy. I'm impressed this went from problem ID to a new test kernel version in 2 months flat. I've pinged Amazon to see if they can get on the track of this too; I suspect they aren't exactly uptaking kernel changes quickly but we'll find out. (Sorry this is a bit delayed, I don't read the list regularly, I come back and search every month to see if anyone's found the problem yet - looks like I hit the jackpot this time!) Ernest I'm not into Cygwin development enough to know what a BLODA is, but you may like to know the bug is in the Xen hypervisor used by Amazon. I don't know exactly what releases or Xen are affected, but for sure all RHEL5 (and CentOS 5) hypervisors are. The reason why you see it only on 64-bit Windows, is that the bug is about Xen mishandling the SWAPGS instruction which, well, is only present in 64-bit processors and in 64-bit mode. https://bugzilla.redhat.com/show_bug.cgi?id=613187 Paolo ps: KVM was also affected until last February. I haven't checked if RHEL/CentOS KVM has the bug, but I'll ask fellow developers around about it. __ UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT information is ENCOURAGED. -- 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: awk gsub problem
On 09/19/2010 02:33 PM, Lee wrote: If LANG is en_US or en_US.utf8, then the regular expression [a-z] does *not* correspond anymore to the ASCII codes. Rather it corresponds to something like [aAbBcCdD...zZ], independent of the actual character encoding ISO-8859-1 or UTF-8. In glibc, [a-z] gets translated according to locale collation order. If A collates before a, then it maps to [aBbCc..Zz], if A collates after a, then it maps to [aAbB...yYz] (notice that in either case, one of the two capital letters is omitted, so it is NOT the same as all 26 letters in both cases). This has been a MUCH complained-about feature of glibc, which has in turn been copied by bash, awk, grep, etc. Note that POSIX explicitly states that [a-z] has unspecified results in any locale except C. So the glibc behavior is permitted, but so is the traditional behavior of just the 26 lowercase letters. If you can convince the glibc folks that [a-z] should have the traditional behavior, more power to you. http://lists.gnu.org/archive/html/bug-grep/2010-09/msg00030.html -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- 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: Unacceptable behavior -- slowing down script execution
On 09/18/2010 05:35 AM, SJ Wright wrote: Is there any reason, when bash itself nowadays has pretty good tab-completion, why bash-completion is still available in setup.exe or elsewhere in the Luniverse? Yes. Builtin bash completion ONLY targets command names (in the first shell word) and file names (in subsequent shell words). The bash-completion package adds context-sensitive tab completion (ssh TAB completes on known machine names, chown TAB completes on known user names, git branch TAB completes on branch names in the current repository, etc.). If you want the additional context sensitivity (which _I_ do), then bash-completion is a must. If you don't mind losing out on the extra context sensitivity and want bash to use less resources, then avoid bash-completion. It's up to you. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org volunteer cygwin bash-completion maintainer -- 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: Unacceptable behavior -- slowing down script execution
mike marchywka wrote: On 9/17/10, SJ Wright sjwright68 charter.net wrote: 4. Is it normal for any script to run CPU usage up to 100%? Unless it is blocking for something like IO including VM swaps, why not? Regarding #4: I have a script that I ran in GNOME Terminal less than an hour ago. I timed it -- the return was 20.6 seconds on the first line (real?). I ran the same script fifteen minutes later, evaluating identical files of the same type, length (5.37kb and 345b ASCII text) and time stamp, and after 7 minutes it was barely one-eighth complete. That's when I checked Task Manager and found my CPU usage was at 100% and three bash.exe's were running simultaneously. Admittedly the script calls on several This sounds like a threading problem if I had to guess but it could be anything that changed between runs- certainly timing will make these things come and go but having no idea what you mean by identical instead of the same there are a lot of things that could have changed etc. What did it seem to be trying to do? Often in cases like this the alarming situation is where your cpu usage drops to low values and your disk light gets stuck on as you have depleted memory. I guess I'm also not sure what you think a usual or good number of processes should be etc. A number of anecdotes have been reported about slower performance on 64 bit or multi core machines than more primitive older cmoputers and it is easy to speculate on reasons why that could happen but hard to make a clear diagnosis without an explicit test case. -- 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 They were the same files, in terms of number of lines, bytes per line, and so forth. Likely the only differences were to be found in their timestamps. This one script seems, now that I've got rid of bash-completion (thanks again Cyrille), to be the only one that will push CPU usage to 100% and keep it there for the duration of its execution. Call me strange, but I like my Task Manager to show me no more than 51 processes at a time. I also like my scripts to call up one and only one additional instance of the shell they're written to be executed in than I'm running before I start one. I agree it's likely a threading problem, but I think it's more likely how I have the script written. A breakdown of the calls to non-internal (not BASH built-ins, so far as I can judge) would look like this: -- 8 to Exiv2 v.0.20 by Andreas Huggel. Likely there are more; I may be wrong. I don't normally keep track of which command came from where or calls on what class of ps- able process. Perhaps, as this has involved and included more than two shells running simultaneously (by visual evidence in Task Manager and nothing else), it is, instead, a matter of a too-high demand *on* the internals. Or I've got another software package, either Cygwin-adapted or just a lucky compile on my part, that's kicking in and making itself known when I launch this one particular script. I can post the script to the list as text if anyone thinks it's worth pursuing this line of logic. Thanks for the replies and the help thus far. Looking forward to the same continuing. Steve Wright -- 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 from linux to cygwin + CUI + Ctrl-C
On 9/20/2010 6:22 AM, Ilia K. wrote: It looks like my reply got lost in mailer's spam filters, reposting. On Wed, Sep 15, 2010 at 5:36 PM, Christopher Faylor wrote: ... Cygwin summarily halts a pure-Windows process on receiving a CTRL-C. There is no way around that other than to relink the program to use Cygwin. Do you state that there is absolutely no way to make it work as I need? This would be very pity... Do you know what's the difference between running bash from sshd and from the desktop? In the later case, Ctrl-C works as expected! To me it looks like cygwin knows how to pass Ctrl-C to native apps, but sshd somehow interferes with it. See http://cygwin.com/cygwin-ug-net/using-cygwinenv.html and look for the 'tty' setting. If you set 'tty' before starting 'bash', you'll see the same issue even using a plain console (cmd.exe). I'm assuming that's what you mean when you say from the desktop above. Actual terminals, rxvt, mintty, etc., will have the same behavior you saw with 'sshd'. Currently, there is no way to support ptys and make Windows understand them as something other than a pipe. -- 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: fvwm ignores clickToFocus for function keys
a) Are you running fvwm under a rootless X11? No, but I will try that at work tomorrow and report back b) are your configs the same? The same as what? Sorry, I don't understand the question. -- 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 with mmap in latest snapshot
My application uses mmap on a 16MB file. On released 1.7.7, there's no
problem. But with the 20100919 snapshot, it crashes when it tries to
access the mmap space past the first 32KB or so. Attached is a simple
test program that illustrates the problem.
* With 1.7.7 *
$ uname -a
CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
$ ./a
creating mmap-test-file
Writing zeros
mmap-ing
writing ones to mmap region
done!
$ ls -l mmap*
-rw-r--r--+ 1 hkehoe Domain Users 16777216 2010-09-20 14:51 mmap-test-file
$ od -tc mmap-test-file
000 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
1
* With snapshot *
$ uname -a
CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.8s(0.231/5/3) 20100919 16:19:37 i686 Cygwin
$ ./a
creating mmap-test-file
Writing zeros
mmap-ing
writing ones to mmap region
Segmentation fault (core dumped)
$ od -tc mmap-test-file
000 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001
*
010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
1
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__#include stdio.h
#include stdlib.h
#include string.h
#include sys/types.h
#include fcntl.h
#include sys/mman.h
#define MMAP_FILE mmap-test-file
#define MMAP_SIZE 16384*1024
main()
{
int fd;
char* maddr;
printf(creating MMAP_FILE \n);
fd = open(MMAP_FILE, O_CREAT|O_TRUNC|O_RDWR, 0666);
if(fd 0)
{
perror(Could not open MMAP_FILE);
exit(1);
}
printf(Writing zeros\n);
{
int n = MMAP_SIZE;
char buf[1024];
memset(buf, 0, 1024);
while(n 0)
{
write(fd, buf, 1024);
n -= 1024;
}
}
printf(mmap-ing\n);
maddr = mmap(NULL, MMAP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if(maddr == NULL || maddr == MAP_FAILED)
{
perror(mmap);
exit(1);
}
printf(writing ones to mmap region\n);
{
int n;
for(n = 0; n MMAP_SIZE; n++)
maddr[n] = 1;
}
printf(done!\n);
}
--
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: Problem with mmap in latest snapshot
On 9/20/2010 3:00 PM, Heath Kehoe wrote: My application uses mmap on a 16MB file. On released 1.7.7, there's no problem. But with the 20100919 snapshot, it crashes when it tries to access the mmap space past the first 32KB or so. Attached is a simple test program that illustrates the problem. The test program also crashes on 20100917, but it works with 20100912. -h __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/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
missing pthread.h in building 64-bit aaplications
Hello All, Goal: Building 64-bit application on Cygwin OS: 64-bit Windows 7 I used x86_64-w64-mingw32-gcc to build the application, but failed. The output tells missing pthread.h. pthread.h is included in one of my source files. I located the file, one in C:\cygwin\usr\include, the other C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include. I tried using -I to tell gcc to include pthread.h, but failed. why? -- View this message in context: http://old.nabble.com/missing-pthread.h-in-building-64-bit-aaplications-tp29764972p29764972.html Sent from the Cygwin list mailing list archive at Nabble.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: missing pthread.h in building 64-bit aaplications
On Mon, Sep 20, 2010 at 05:01:52PM -0700, ke...@ca wrote: Hello All, Goal: Building 64-bit application on Cygwin OS: 64-bit Windows 7 I used x86_64-w64-mingw32-gcc to build the application, but failed. The output tells missing pthread.h. pthread.h is included in one of my source files. I located the file, one in C:\cygwin\usr\include, the other C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include. I tried using -I to tell gcc to include pthread.h, but failed. why? This is a MinGW compiler. It doesn't support pthread. Any threading support would be with standard Windows calls. 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: missing pthread.h in building 64-bit aaplications
On 9/20/2010 10:18 PM, Christopher Faylor wrote: On Mon, Sep 20, 2010 at 05:01:52PM -0700, ke...@ca wrote: I used x86_64-w64-mingw32-gcc to build the application, but failed. The output tells missing pthread.h. pthread.h is included in one of my source files. I located the file, one in C:\cygwin\usr\include, the other C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include. I tried using -I to tell gcc to include pthread.h, but failed. why? This is a MinGW compiler. It doesn't support pthread. Any threading support would be with standard Windows calls. I don't think that's accurate. The x86_64-mingw64 cross compiler package set includes a win32-pthreads package, including pthread.h. It's necessary for gcc's OMP support via libgomp. That's why the OP was able to find one copy of pthread.h in C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include. The real question is why the (cross)compiler couldn't locate it; given the whole /mingw prefix and sysroot support, it really should be able to. -- 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
Re: missing pthread.h in building 64-bit aaplications
On Mon, 2010-09-20 at 17:01 -0700, ke...@ca wrote: I used x86_64-w64-mingw32-gcc to build the application, but failed. The output tells missing pthread.h. pthread.h is included in one of my source files. I located the file, one in C:\cygwin\usr\include, the other C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include. I tried using -I to tell gcc to include pthread.h, but failed. why? Keep in mind that the new mingw* compilers are Cygwin-hosted cross-compilers: they use standard *NIX paths. In any case, if mingw64-x86_64-pthreads is installed, then you don't need an -I flag at all; pthread.h should already be in the default search path. Yaakov -- 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: missing pthread.h in building 64-bit aaplications
On Mon, Sep 20, 2010 at 10:38:48PM -0400, Charles Wilson wrote: On 9/20/2010 10:18 PM, Christopher Faylor wrote: On Mon, Sep 20, 2010 at 05:01:52PM -0700, ke...@ca wrote: I used x86_64-w64-mingw32-gcc to build the application, but failed. The output tells missing pthread.h. pthread.h is included in one of my source files. I located the file, one in C:\cygwin\usr\include, the other C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include. I tried using -I to tell gcc to include pthread.h, but failed. why? This is a MinGW compiler. It doesn't support pthread. Any threading support would be with standard Windows calls. I don't think that's accurate. The x86_64-mingw64 cross compiler package set includes a win32-pthreads package, including pthread.h. It's necessary for gcc's OMP support via libgomp. Yeah, duh. I should have picked up on that from the report. Sorry for the noise. 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
