Trouble with the xwin and ms remote desktop
I have been running Xwin on xp pro for a week along with xterms and emacs on my desktop. I then tried to remote connect (ms remote desktop: mstsc.exe) to the desktop from a laptop across the internet. 1) As soon as I had connected to my desktop (which was running xwin), the xserver crashed. I could see the rest of the ms xp apps on the remote screen though. The laptop has a 14 screen whereas the desktop has twin 19 screens. I then re-started the xserver from the remote laptop while connecting to the desktop, which seemed to be working fine as long as I stayed on the laptop. 2) When I got back to my desktop, the xserver still thought that the laptop's screen was in use, and wouldnt display correctly past the top two thirds of screen 0. I guess this makes sense since the xserver knew of the smaller screen size when it was started during the remote session. Consequently, anything on the bottom of the screen would not draw at all, or refresh properly. i.e. if I had an xterm on the lower end of the monitor, it would not accept any key strokes until I moved the xterm to the top two-thirds of the screen. Is there any way to request Xwin.exe to dynamically resize itself rather than bouncing the xserver a specific size/resolution profile ?? Otherwise, I might have to bounce the xserver every time i alternate between the desktop and the laptop. Thanks, Sunil Matta -- 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/
Fwd: strange behavior with threads...
Hi!
can someone help me regarding this issue?
I have a multithreaded application (one thread for the GUI and one
thread for background processing [which only sleep at this time]) and
I'm getting connection errors only on cygwin/X (tested on linux and
linux in vm, 2 different linux distribution)
normally all X operation shall be protected with mutexes
any idea?
thanks
JLM
-- Forwarded message --
From: jean-luc malet jeanluc.ma...@gmail.com
Date: Fri, Jul 24, 2009 at 11:12 AM
Subject: Re: strange behavior with threads...
To: cyg...@cygwin.com
On Thu, Jul 23, 2009 at 4:11 PM, Corinna
Vinschencorinna-cyg...@cygwin.com wrote:
On Jul 23 15:50, jean-luc malet wrote:
Hi!
I've the following code :
void _Window::Start(void* arg)
{
ThreadArgs args;
args.TheWindow=this;
args.args=arg;
int err = pthread_create(main_thread,NULL,_Start, (void*)args);
if (err)
{
throw new Exception(err, window thread creation error);
}
}
void* _Window::_Start(void* arg)
{
ThreadArgs* args = (ThreadArgs*) arg;
pthread_exit((void*)args-TheWindow-start_routine(args-args));
}
_Window::_Start is static
for some reason that I can't determine it happens that args in
_Window::_Start have strange value (args-TheWindow don't contain a
valid pointer, ie a pointer on a _Window object)
Maybe you shouldn't let the arg to the thread point to a local
stack-based variable in the other method which, as you code implies,
returns after having started the thread...
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
Yes, sorry for such lame question :( I should have seen this issue
the code has been modified and has been tested under linux and is now
working as expected under linux, thanks
however I have a X server connection issue
freeglut (./tests/GENERATED/GlutWindowTest): Unable to create direct
context rendering for window ' '
This may hurt performance.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :0.0
after 34 requests (32 known processed) with 5 events remaining.
think I will have to post on Cygwin/X ML
thanks for help
JLM
--
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!
-
Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre. Betty
Reese
http://www.grainesdechangement.com/citations.htm
--
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!
-
Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre. Betty
Reese
http://www.grainesdechangement.com/citations.htm
--
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: Problem with multiwindow and drop-down menus
On 22/07/2009 20:44, David Rothenberger wrote: I'm having a problem with 1.7 when starting the server with -multiwindow. I am trying to run Sun's jconsole application (part of the JDK 6) remotely, but none of the menus work correctly. When I run a separate window manager (wmaker), they work correctly. I can click on a menu and it will stay open. I can move my mouse to select a menu entry and then click again to make it so. With -multiwindow, clicking on the menu just causes it to flash open. If I hold the mouse down, the menu will stay open, but I can't select any options. The only way I can interact with jconsole is with keyboard shortcuts. Any ideas? Is this some local configuration problem or a known issue with -multiwindow? There was a change in the most recent X server, xorg-server-1.6.2-2, which attempts to improve the behaviour of X window menus. Can you try with that and see if it makes a difference? -- 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: Is there a Windows clipboard manager that doesn't clash with -clipboard parameter?
On 24/07/2009 07:47, Alister Hood wrote: I've found that -clipboard clashes with Windows clipboard history managers such as Ditto. Does anybody know of a clipboard manager with which it does work? If I run glipper in a linux panel in Colinux, then I can use that, and I imagine I could compile them for Cygwin instead, but the panel is handled as a window (I'm using -multiwindow), and I'd rather use a native Windows clipboard manager anyway, so I can only start X when I need to. Since xorg-server 1.6.0, we've reverted an upstream patch [1], which was causing the built-in clipboard synchronization client to fight with other clipboard monitoring applications. Looking at the other responses, it seems like this has had the desired effect :-) [1] http://bugs.freedesktop.org/show_bug.cgi?id=5735 -- 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: patch for multiwindow support of _NET_WM_STATE_SKIP_TASKBAR
On 28/07/2009 07:14, Russell Davis wrote: I found a great patch on this list from back in January - see http://www.cygwin.com/ml/cygwin-xfree/2009-01/msg00068.html. I'm not sure if 'great' here means 'I like the idea of it' or 'I've tested it and it works well', but thank you :-) It would great to see that patch make it to the source tree, but as far as I can tell that hasn't happened. Anyone know any more details about that? As it says at the end of that mail, still needs more testing and work. There's been a bit more work at [1], but beyond getting the patch itself to work correctly, it unfortunately seems that it also exposes some race conditions lurking in the -multiwindow code, which need also fixing before it's safe to include this patch, and somebody has to do that. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=9852 Does someone just need to submit it to the cygwin-patches list? No, the cygwin-patches list is for patches to the cygwin DLL. This is the correct list for discussion of patches to the Cygwin/X server. -- 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: Trouble with the xwin and ms remote desktop
On 29/07/2009 14:45, Matta, Sunil wrote: I have been running Xwin on xp pro for a week along with xterms and emacs on my desktop. I then tried to remote connect (ms remote desktop: mstsc.exe) to the desktop from a laptop across the internet. 1) As soon as I had connected to my desktop (which was running xwin), the xserver crashed. I could see the rest of the ms xp apps on the remote screen though. The laptop has a 14 screen whereas the desktop has twin 19 screens. I then re-started the xserver from the remote laptop while connecting to the desktop, which seemed to be working fine as long as I stayed on the laptop. 2) When I got back to my desktop, the xserver still thought that the laptop's screen was in use, and wouldnt display correctly past the top two thirds of screen 0. I guess this makes sense since the xserver knew of the smaller screen size when it was started during the remote session. Consequently, anything on the bottom of the screen would not draw at all, or refresh properly. i.e. if I had an xterm on the lower end of the monitor, it would not accept any key strokes until I moved the xterm to the top two-thirds of the screen. Is there any way to request Xwin.exe to dynamically resize itself rather than bouncing the xserver a specific size/resolution profile ?? Otherwise, I might have to bounce the xserver every time i alternate between the desktop and the laptop. This is a known limitation. The only workaround is to restart the Xserver when the display resolution changes. Having used the Xserver in a similar way, I do know how irritating that is :-) This is the Windows display size/Monitor count/position changes while running. item on the todo list at [1], as connecting via RDP with a different desktop size effectively changes the display size However, this shouldn't be causing a crash, so if you could provide the /var/log/Xwin.0.log for a session when that happens, that would be useful. [1] http://x.cygwin.com/devel/todo.html -- 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: Is there a Windows clipboard manager that doesn't clash with -clipboard parameter?
Alister Hood alister.hood at synergine.com writes: Hi, I've found that -clipboard clashes with Windows clipboard history managers such as Ditto. Does anybody know of a clipboard manager with which it does work? I have had awful troubles using XWin with -clipboard. I don't think I am doing anything odd with the XP clipboard AFAIK. Using -clipboard crashes various applications (tgif) and gives performance issues in others (LyX) I tried a re-install for xwin but it seems to give me the version from February, 1.5.3.0 (20090222) Looking at the package list for cygwin, it appears the xwin package is obsolete? What am I doing wrong? -- 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: Trouble with the xwin and ms remote desktop
Jon: Thanks for the response. I have been running Xwin on xp pro for a week along with xterms and emacs on my desktop. I then tried to remote connect (ms remote desktop: mstsc.exe) to the desktop from a laptop across the internet. 1) As soon as I had connected to my desktop (which was running xwin), the xserver crashed. I could see the rest of the ms xp apps on the remote screen though. The laptop has a 14 screen whereas the desktop has twin 19 screens. I then re-started the xserver from the remote laptop while connecting to the desktop, which seemed to be working fine as long as I stayed on the laptop. 2) When I got back to my desktop, the xserver still thought that the laptop's screen was in use, and wouldnt display correctly past the top two thirds of screen 0. I guess this makes sense since the xserver knew of the smaller screen size when it was started during the remote session. Consequently, anything on the bottom of the screen would not draw at all, or refresh properly. i.e. if I had an xterm on the lower end of the monitor, it would not accept any key strokes until I moved the xterm to the top two-thirds of the screen. Is there any way to request Xwin.exe to dynamically resize itself rather than bouncing the xserver a specific size/resolution profile ?? Otherwise, I might have to bounce the xserver every time i alternate between the desktop and the laptop. This is a known limitation. The only workaround is to restart the Xserver when the display resolution changes. Having used the Xserver in a similar way, I do know how irritating that is :-) I was hoping there would be a xserver.resize() function that could be called from the xroot menu, but I guess not. This would definitely save a lot of headaches, when switching between different display sizes and resolutions. This is the Windows display size/Monitor count/position changes while running. item on the todo list at [1], as connecting via RDP with a different desktop size effectively changes the display size However, this shouldn't be causing a crash, so if you could provide the /var/log/Xwin.0.log for a session when that happens, that would be useful. The xserver on the desktop definitely crashed the first time I connected from a laptop which had never been used before. I will have to observe if this happens again. Thanks again. [1] http://x.cygwin.com/devel/todo.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/mingw ChangeLog mingwex/stdio/pformat.c
CVSROOT:/cvs/src Module name:src Changes by: keithmarsh...@sourceware.org2009-07-29 07:22:51 Modified files: winsup/mingw : ChangeLog winsup/mingw/mingwex/stdio: pformat.c Log message: Correct disposition of wchar_t output in printf(). Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.443r2=1.444 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/stdio/pformat.c.diff?cvsroot=srcr1=1.6r2=1.7
src/winsup/mingw ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2009-07-30 01:55:44 Modified files: winsup/mingw : ChangeLog Log message: Fix formatting issue with last entry Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.444r2=1.445
Re: Emacs can't start-process more than 30~40 processes
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes: On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote: I have debugged it again, and I think I have more clue. I have read the how-cygheap-works.txt, and this might be a known problem. It's because the cygheap space has been used up. With Procexp, I can see cygwin1.dll is based 0x6100, with size 0x30 (3M). When segfault is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called with a increase of (gdb) p sbs $16 = 65544 This will increase cyghead to 0x6165e92c, but from Proxexp I can see cygncurses-9.dll is based at 0x6165. Besides, this code snippet from pipe.cc fhandler_pipe::create didn't check for NULL pointer, and directly caused the segfault. fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev); fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev); //bhj: we should check NULL here. Not necessarily. We don't expect these functions to return NULL. It would be interesting to know how many fds are open at this point. If it is a large number then maybe we have to start enforcing an fd max. If it is a small number then something is wrong and we're allocating too much of the cygheap. The cygheap was always supposed to be relatively small. Maybe we're abusing it too much in 1.7. There are quite some fds. In start-process, emacs will allocate 1 PTY and 1 pipe for each process it starts. Each fhandler_base is about 32K, but the _csbrk must allocate 65544 bytes for it. -- 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: Invalid csih method in ssh-user-config scripts
On Jul 28 23:41, Steven Hartland wrote: In the latest version of ssh-user-config from 1.7 it uses the method csih_error_multiline which doesn't exist, I assume this should be csih_error_multi from: /usr/share/csih/cygwin-service-installation-helper.sh Thanks for the report. I uploaded a new openssh package with the fixed script. 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: mingw headers and libraries missing
Wow, sounds I have all the experts sitting together in this list. Maybe you can help me once more: First a brief plan: I'm working for the ATLAS-Collaborationand we need for detectordevelopment a programinterface. We have one really big and really old programm written in LabWindows C Code (of course in Windows) this is really a mess. And we have a big new program which is almost platform-independet (http://projects.hepforge.org/eudaq/ ). These programs shound communicate with each other. As the eudaq-code is running very well on cygwin I thought it would be easy to write a dll for accessing it from windows. The LabWindow-thing can handle this - I tried this out. So I changed the source-code a bit so that eudaq-software compiles with -mno-cygwin. In deed I get it compilable. But then the code is not running. For me two major problems have focussed out: I have a dependency on sys/selector.h and a dependency on pthread.h I think I can link against this external pthread-libraries (http://sourceware.org/pthreads-win32/ ). And I found a switch inside the code for linking against winsock(2).h This switch is for beeing compatible with Visual C++, which actually is not working. I'm not really sure if I can use the windows-like winsock environment in cygwin. Is it really compatible? What does this stuff with posix and so on mean in detail? What do you think? Is it easier to get this stuff running in cygwin or to make it possible in Visual C++? I would definetly prefer the first one. How far is the development of the windows cross-compiler really? -- 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
MVFS on cygwin: Thanks, and plug for ClearCase::Wrapper::MGi
Thanks for the recent fixes to make cygwin support mvfs for handling the emacs symlink locks! I keep updating my CPAN modules to run ClearCase from cygwin. With the recent ClearCase::Argv 1.46, and ClearCase::Wrapper::MGi 0.11, I get the following kind of transcripts: ClearCase-Wrapper-MGi mount //view/emagiro_cw /view/emagiro_cw mount: warning - /view/emagiro_cw does not exist. mount: defaulting to 'notexec' mount option for speed since native path references a remote share. Use '-f' option to override. ClearCase-Wrapper-MGi cd /view/emagiro_cw/atcctest/foo foo ct ls -d . .@@/main/mg/1Rule: .../mg/LATEST foo ct co -/dbg=1 -nc . = des -fmt %m . = ls -d . = co -nc . Checked out . from version /main/mg/1. foo ct unco -/dbg=1 -rm . = ls -s -d . = unco -rm . Checkout cancelled for .. The wrapper has still some limitations. From a naive user's point of view, its inconsistent support for interactive prompts from cleartool is probably the most annoying... Marc -- View this message in context: http://www.nabble.com/MVFS-on-cygwin%3A-Thanks%2C-and-plug-for-ClearCase%3A%3AWrapper%3A%3AMGi-tp24715103p24715103.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: How to install-libLTLIBRARIES dll to bin?
Charles Wilson wrote: Dave Korn wrote: Only libtool knows about the DLL. Only the Makefile knows about the setting of $bindir from configure. Currently however the Makefile only passes the path to the output in $libdir. Therefore ISTM that the only correct solution is to add a --bindir= option to libtool and modify automake or libtoolise to ensure it gets passed by the makefiles when they invoke libtool. Agreed. This is still on my TODO list for the cygwin version of libtool, and (obviously) for eventual submission to upstream. However, if somebody beats me to it, PTC. Something like this? Untested as yet, I'm going to put it through a gcc bootstrap cycle. Should I be worried about stripping any final slash off the -bindir option to avoid inadvertent doubling-up when I append /bin/..., do you reckon? cheers, DaveK diff --git a/Makefile.am b/Makefile.am index a18955e..129b890 100644 --- a/Makefile.am +++ b/Makefile.am @@ -494,7 +494,8 @@ TESTSUITE_AT = tests/testsuite.at \ tests/configure-iface.at \ tests/stresstest.at \ tests/cmdline_wrap.at \ - tests/darwin.at + tests/darwin.at \ + tests/win32.at EXTRA_DIST += $(srcdir)/$(TESTSUITE) $(TESTSUITE_AT) $(srcdir)/tests/package.m4 diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh old mode 100644 new mode 100755 index ebd3909..a1889d3 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially: -all-static do not do any dynamic linking at all -avoid-versiondo not add a version suffix if possible + -bindir BINDIRspecify path to $prefix/bin (needed only when installing +a Windows DLL) -dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsym(3) @@ -3659,6 +3661,7 @@ func_mode_link () new_inherited_linker_flags= avoid_version=no +bindir= dlfiles= dlprefiles= dlself=no @@ -3751,6 +3754,11 @@ func_mode_link () esac case $prev in + bindir) + bindir=$arg + prev= + continue + ;; dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. @@ -4012,6 +4020,11 @@ func_mode_link () continue ;; + -bindir) + prev=bindir + continue + ;; + -dlopen) prev=dlfiles continue @@ -7706,7 +7719,13 @@ EOF # place dlname in correct position for cygwin tdlname=$dlname case $host,$output,$installed,$module,$dlname in - *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;; + *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) + tdlname=../bin/$dlname + if test x$bindir != x ; + then + tdlname=$bindir/$dlname + fi + ;; esac $ECHO $output \ # $outputname - a libtool library file -- 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: How to install-libLTLIBRARIES dll to bin?
Den 2009-07-29 11:46 skrev Dave Korn: Charles Wilson wrote: Dave Korn wrote: Only libtool knows about the DLL. Only the Makefile knows about the setting of $bindir from configure. Currently however the Makefile only passes the path to the output in $libdir. Therefore ISTM that the only correct solution is to add a --bindir= option to libtool and modify automake or libtoolise to ensure it gets passed by the makefiles when they invoke libtool. Agreed. This is still on my TODO list for the cygwin version of libtool, and (obviously) for eventual submission to upstream. However, if somebody beats me to it, PTC. Something like this? Untested as yet, I'm going to put it through a gcc bootstrap cycle. Should I be worried about stripping any final slash off the -bindir option to avoid inadvertent doubling-up when I append /bin/..., do you reckon? I don't think it's that easy, the dlname in the .la file is relative to the position of the .la file itself. It's simply not intended to to be an absolute path. And you forgot the file tests/win32.at in the patch... Cheers, Peter -- 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: How to install-libLTLIBRARIES dll to bin?
Peter Rosin wrote: I don't think it's that easy, the dlname in the .la file is relative to the position of the .la file itself. It's simply not intended to to be an absolute path. Argh. Tell you what, let's change it from -bindir to -relative-bindir and just say that you have to pass in ../../../../bin/ or whatever you want. And you forgot the file tests/win32.at in the patch... Yeh, haven't got beyond a skeleton for that yet, this is WIP :) cheers, DaveK -- 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] New package: cppcheck-1.34-1
Version 1.34-1 of cppcheck has been uploaded. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler don't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes various compiler extensions, inline assembly code, etc. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, 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. -- Chris Sutcliffe http://emergedesktop.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: AWK from a batch file
On Tue, Jul 28, 2009 at 12:42 PM, Matthew Swanson wrote:
I am attempting to run AWK in a bash window through a Windows batch file. I
am using:
echo awk -v FS=',' -v OFS=',' '^{ awk.s
echo if ^($2 ~ /^^[0-9]*$/^) awk.s
echo print $0 ^^ good_file.txt awk.s
echo else awk.s
echo print $0 ^^ bad_file.txt awk.s
echo ^}' input_file.txt awk.s
OK, so you are creating a bash script from CMD. Invoking it outside
of Cygwin means the normal bash startup files are not run, so $PATH is
not set, so it can't find any commands. Replace awk with /bin/awk
and you should be good, apart from the lack of execute permission.
The second problem is that CMD's echo appends carraige returns.
Add these commands to fix both that problem and the execute permission
one:
\cygwin\bin\d2u awk.s
\cygwin\bin\chmod +x awk.s
--
Mark J. Reed markjr...@gmail.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: Python-devel on Windows XP build
Gwen, On Wed, Jul 29, 2009 at 02:57:38AM -0400, Gwen Morse wrote: I'm trying to compile Tinyfuge with python extensions on my Windows XP box. I have the source which is reported by friends to compile properly on linux systems. ./configure fails, checking the log I see this message: configure:8153: result: no configure:8169: checking for strstr configure:8226: gcc -o conftest.exe -g -O2 -DTFPYTHON -I/usr/include/python2.5 -Lpcre-2.08 conftest.c -lssl -lcrypto -lpython2.5 5 conftest.c:68: warning: conflicting types for built-in function 'strstr' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lpython2.5 The following will solve the above build problem: LDFLAGS=-L/usr/lib/python2.5/config configure Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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
Fresh install of Cygwin on Vista with no Home drectiory
Wheres home gone ? I installed fresh Cygwin on Vista Enterprise, but I don't seem to have a home directory ? Many thanks in advance, Aaron -- 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: Python-devel on Windows XP build
Jason Tishler wrote: Gwen, On Wed, Jul 29, 2009 at 02:57:38AM -0400, Gwen Morse wrote: I'm trying to compile Tinyfuge with python extensions on my Windows XP box. I have the source which is reported by friends to compile properly on linux systems. ./configure fails, checking the log I see this message: configure:8153: result: no configure:8169: checking for strstr configure:8226: gcc -o conftest.exe -g -O2 -DTFPYTHON -I/usr/include/python2.5 -Lpcre-2.08 conftest.c -lssl -lcrypto -lpython2.5 5 conftest.c:68: warning: conflicting types for built-in function 'strstr' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lpython2.5 The following will solve the above build problem: LDFLAGS=-L/usr/lib/python2.5/config configure Jason I believe you're meant to specify LDFLAGS after the 'configure' these days, i.e. as an argument to configure, not a shell variable. ./configure LDFLAGS=-L/usr/lib/python2.5/config other args ... cheers, DaveK -- 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: Fresh install of Cygwin on Vista with no Home drectiory
2009/7/29 Aaron Gray aaronngray.li...@googlemail.com Wheres home gone ? Helps to run Bash ! Sorry for the noise, Aaron -- 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: Python-devel on Windows XP build
Dave, On Wed, Jul 29, 2009 at 04:27:20PM +0100, Dave Korn wrote: Jason Tishler wrote: The following will solve the above build problem: LDFLAGS=-L/usr/lib/python2.5/config configure Jason I believe you're meant to specify LDFLAGS after the 'configure' these days, i.e. as an argument to configure, not a shell variable. ./configure LDFLAGS=-L/usr/lib/python2.5/config other args ... I wasn't aware LDFLAGS, etc. is suppose to be specified after configure. FWIW, I actually tried the command line above (i.e., LDFLAGS specified before configure) and it seemed to work. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: Python-devel on Windows XP build
Jason Tishler wrote: Dave, On Wed, Jul 29, 2009 at 04:27:20PM +0100, Dave Korn wrote: Jason Tishler wrote: The following will solve the above build problem: LDFLAGS=-L/usr/lib/python2.5/config configure Jason I believe you're meant to specify LDFLAGS after the 'configure' these days, i.e. as an argument to configure, not a shell variable. ./configure LDFLAGS=-L/usr/lib/python2.5/config other args ... I wasn't aware LDFLAGS, etc. is suppose to be specified after configure. FWIW, I actually tried the command line above (i.e., LDFLAGS specified before configure) and it seemed to work. It does, at least most of the time, and it did used to be the standard way of doing things, but it's deprecated now in favour of: $ /gnu/gcc/gcc/configure --help `configure' configures this package to adapt to many kinds of systems. Usage: /gnu/gcc/gcc/configure [OPTION]... [VAR=VALUE]... To assign environment variables (e.g., CC, CFLAGS...), specify them as VAR=VALUE. See below for descriptions of some of the useful variables. cheers, DaveK -- 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: bash pipeline exit code - possible race condition?
On 07/29/2009 01:16 AM, David Antliff wrote: I've noticed a strange problem with bash pipelines in Cygwin that might indicate some sort of race condition. I cannot reproduce the problem on a Linux system, but it seems easy to reproduce in Cygwin. snip I am running Cygwin on Windows XP (service pack 3). $ uname -srv CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 Want to try the test again with the upcoming Cygwin 1.7 release? http://cygwin.com/#beta-test 1.5.x is will be replaced by it very shortly so unless the problem is still visible in 1.7, it's not likely to spark much investigation. Just FYI. -- 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: bash pipeline exit code - possible race condition?
Larry Hall (Cygwin) wrote: On 07/29/2009 01:16 AM, David Antliff wrote: I've noticed a strange problem with bash pipelines in Cygwin that might indicate some sort of race condition. I cannot reproduce the problem on a Linux system, but it seems easy to reproduce in Cygwin. snip I am running Cygwin on Windows XP (service pack 3). $ uname -srv CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 Want to try the test again with the upcoming Cygwin 1.7 release? http://cygwin.com/#beta-test 1.5.x is will be replaced by it very shortly so unless the problem is still visible in 1.7, it's not likely to spark much investigation. Just FYI. It reproduces for me under 1.7, but I haven't had time to look closer yet. Thanks for the nice simple testcase, David! cheers, DaveK -- 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: strange behavior with threads...
On Fri, Jul 24, 2009 at 8:43 PM, benadam777benadam7...@gmail.com wrote: jean-luc malet wrote: I have a X server connection issue freeglut (./tests/GENERATED/GlutWindowTest): Unable to create direct context rendering for window ' ' This may hurt performance. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server :0.0 after 34 requests (32 known processed) with 5 events remaining. I receive the same error when running ubuntu in a virtual environment and everything I have found regarding that issue points to either improper configuration of xorg.conf for multiple video cards or video cards that don't support OpenGL. -- I just tried with ubuntu in a virtual environment and everything run fine, seems to come from cygwin/X Best Regards, JLM -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- 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: mingw headers and libraries missing
Ok, thank you all for reading this stuff I'm able to run the code now with visual c++. I had never thought I would use it ;-) actually it took me 3 hours to run a hello world and anther 6 to run the code however thanks a lot. and please let me now when the cross-comipler is working Georg Am 29.07.2009 um 10:53 schrieb Georg Troska: Wow, sounds I have all the experts sitting together in this list. Maybe you can help me once more: First a brief plan: I'm working for the ATLAS-Collaborationand we need for detectordevelopment a programinterface. We have one really big and really old programm written in LabWindows C Code (of course in Windows) this is really a mess. And we have a big new program which is almost platform-independet (http://projects.hepforge.org/eudaq/ ). These programs shound communicate with each other. As the eudaq-code is running very well on cygwin I thought it would be easy to write a dll for accessing it from windows. The LabWindow-thing can handle this - I tried this out. So I changed the source-code a bit so that eudaq-software compiles with -mno-cygwin. In deed I get it compilable. But then the code is not running. For me two major problems have focussed out: I have a dependency on sys/selector.h and a dependency on pthread.h I think I can link against this external pthread-libraries (http://sourceware.org/pthreads-win32/ ). And I found a switch inside the code for linking against winsock(2).h This switch is for beeing compatible with Visual C++, which actually is not working. I'm not really sure if I can use the windows-like winsock environment in cygwin. Is it really compatible? What does this stuff with posix and so on mean in detail? What do you think? Is it easier to get this stuff running in cygwin or to make it possible in Visual C++? I would definetly prefer the first one. How far is the development of the windows cross-compiler really? -- 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: Emacs can't start-process more than 30~40 processes
On Wed, Jul 29, 2009 at 03:32:28PM +0800, Haojun Bao wrote: Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes: On Tue, Jul 28, 2009 at 10:52:44AM +0800, Haojun Bao wrote: I have debugged it again, and I think I have more clue. I have read the how-cygheap-works.txt, and this might be a known problem. It's because the cygheap space has been used up. With Procexp, I can see cygwin1.dll is based 0x6100, with size 0x30 (3M). When segfault is about to happen, cygheap_max is 0x6164e924, and the _csbrk is called with a increase of (gdb) p sbs $16 = 65544 This will increase cyghead to 0x6165e92c, but from Proxexp I can see cygncurses-9.dll is based at 0x6165. Besides, this code snippet from pipe.cc fhandler_pipe::create didn't check for NULL pointer, and directly caused the segfault. fhs[0] = (fhandler_pipe *) build_fh_dev (*piper_dev); fhs[1] = (fhandler_pipe *) build_fh_dev (*pipew_dev); //bhj: we should check NULL here. Not necessarily. We don't expect these functions to return NULL. It would be interesting to know how many fds are open at this point. If it is a large number then maybe we have to start enforcing an fd max. If it is a small number then something is wrong and we're allocating too much of the cygheap. The cygheap was always supposed to be relatively small. Maybe we're abusing it too much in 1.7. There are quite some fds. In start-process, emacs will allocate 1 PTY and 1 pipe for each process it starts. Yes, I assumed that there were a bunch of fds but I was looking for an exact number rather than quite some. I can't give exact details about how to find the number now but I thought that since you were looking at the code it wouldn't be too hard to figure this value out. Anyway, Corinna has a stopgap fix for this which will probably show up in a 1.7.0-* release sometime soon. 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: bash pipeline exit code - possible race condition?
On Wed, Jul 29, 2009 at 05:16:24PM +1200, David Antliff wrote: I've noticed a strange problem with bash pipelines in Cygwin that might indicate some sort of race condition. I cannot reproduce the problem on a Linux system, but it seems easy to reproduce in Cygwin. I'm running the following command in a bash script that builds some software: /usr/bin/make --version | head -1 I then test the exit code ($?) against zero and abort if it's non-zero. Before this executes I have set: set -o pipefail This is to ensure that if any command in a pipeline fails, the entire command will return a failed error code. I.e. if make returns non-zero, then $? will be non-zero. Without pipefail, $? is set to the exit code of the last process in the pipeline (head), regardless of the error code of preceding programs (make). I am doing this because I want the script to log the version of Make that it is using, as well as verify that the make binary is present. Most of the time this works fine, $? is zero, and the script continues happily. However occasionally $? comes back as the value 141. I think that this value is coming from make because if I turn pipefail off, the error code is always zero and never 141, and there's nothing else in the pipeline. QED. This is very curious (and causes my script to break occasionally) so I wrote a little script to test this out: #!/bin/bash set -o pipefail err_count=0 count=0 while : ; do count=$((count + 1)) /usr/bin/make --version | head -1 /dev/null EC=$? if (( EC != 0 )) ; then err_count=$((err_count+1)) echo $count : $EC ($err_count) fi done This doesn't appear to be a cygwin problem. I get occasional errors on linux as well. 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: Emacs can't start-process more than 30~40 processes
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com writes: On Wed, Jul 29, 2009 at 03:32:28PM +0800, Haojun Bao wrote: Not necessarily. We don't expect these functions to return NULL. It would be interesting to know how many fds are open at this point. If it is a large number then maybe we have to start enforcing an fd max. If it is a small number then something is wrong and we're allocating too much of the cygheap. The cygheap was always supposed to be relatively small. Maybe we're abusing it too much in 1.7. There are quite some fds. In start-process, emacs will allocate 1 PTY and 1 pipe for each process it starts. Yes, I assumed that there were a bunch of fds but I was looking for an exact number rather than quite some. I can't give exact details about how to find the number now but I thought that since you were looking at the code it wouldn't be too hard to figure this value out. Sorry. There are a total of 40 fds in one test run from /proc/PID/fd. Seems the PTYs and pipes are allocated and released soon, what remains are /dev/ptmx fds. $'ls' -l /proc/5668/fd total 0 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 0 - /dev/tty2 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 1 - /dev/tty2 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 2 - /dev/tty2 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 37 - /dev/tty36 lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 38 - pipe:[2180]| lrwxrwxrwx 1 bhj None 0 2006-12-01 08:00 39 - pipe:[2232]| ... #bhj: fd 3-36 are all opened - /dev/ptmx ... -- 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: bash pipeline exit code - possible race condition?
On Thu, Jul 30, 2009 at 11:31, Christopher Faylorcgf-use-the-mailinglist-ple...@cygwin.com wrote: On Wed, Jul 29, 2009 at 05:16:24PM +1200, David Antliff wrote: I've noticed a strange problem with bash pipelines in Cygwin that might indicate some sort of race condition. I cannot reproduce the problem on a Linux system, but it seems easy to reproduce in Cygwin. This doesn't appear to be a cygwin problem. I get occasional errors on linux as well. I tried to reproduce on Linux but without success - did you simply run my script or perhaps something else? Do you see error 141 as well? If that is the case, then I might take this to... the bash people? the make people? Hmmm -- 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
