Re: Test and upload: ctags 5.7
http://tangentsoft.net/cygwin/ctags-5.7-1-src.tar.bz2
http://tangentsoft.net/cygwin/ctags-5.7-1.tar.bz2
Tar builds fine, but few observations:
- move documentation in /usr/share/doc
- /usr/share/doc/Cygwin/ctags-5.7-1.README is missing
You can grab template at
http://cante.net/cgi-bin/gitweb.cgi?p=cygbuild.gita=blob_plainf=etc/template/package.READMEh=2e59bf337d757b05b1742ef4ab4e85e79e9c7ee3
Jari
$ sh ctags-5.7-1.sh all
$ tar jxf ctags-5.7-1.tar.bz2 | awk '{print $6}'
usr/bin/ctags.exe
usr/share/man/man1/ctags.1
usr/doc/ctags-5.7/COPYING
usr/doc/ctags-5.7/EXTENDING.html
usr/doc/ctags-5.7/ctags.html
usr/doc/ctags-5.7/FAQ
usr/doc/ctags-5.7/INSTALL
usr/doc/ctags-5.7/INSTALL.oth
usr/doc/ctags-5.7/NEWS
usr/doc/ctags-5.7/README
--
Welcome to FOSS revolution: we fix and modify until it shines
Xwin terminates when followed by xmodmap
To change the behaviour of some function keys I used the xmodmap function in my startxwin.sh When starting XWin with 3 screens (startxwin.sh 3), xwin terminates when defining the keys. When I start Xwin using only one screen (startxwin.sh 1) there is no problem en the function keys are well defined. I tried a sleep 5, but this didn't bring anything. Best regards, Adri #! /bin/sh export DISPLAY=127.0.0.1:0.0 export PATH=/usr/X11R6/bin:$PATH export XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults export XCMSDB=/usr/X11R6/lib/X11/Xcms.txt export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB export XNLSPATH=/usr/X11R6/lib/X11/locale # Cleanup from last run. #rm -rf /tmp/.X11-unix # The error Fatal server error: could not open default font 'fixed' is # caused by using a DOS mode mount for the mount that the Cygwin/X # fonts are accessed through. See the Cygwin/X FAQ for more # information: # http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof # Brief descriptions of XWin-specific options: # # -screen scr_num [width height] # Enable screen scr_num and optionally specify a width and # height for that screen. # Most importantly, any parameters specified before the first -screen # parameter apply to all screens. Any options after the first -screen # parameter apply only to the screen that precedes the parameter. # Example: # XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2 # All screens will be fullscreen, but screen 2 will be depth 8, while # screens 0 and 1 will be the default depth (whatever depth Windows # is currently running at). # -multiwindow # Start an integrated Windows-based window manager. Not to be used # with -rootless nor -fullscreen. # -rootless # Use a transparent root window with an external window manager # (such as twm). Not to be used with -multiwindow nor # with -fullscreen. # -fullscreen # Use a window as large as possible on the primary monitor. # -multiplemonitors # Create a root window that covers all monitors on a # system with multiple monitors. # -clipboard # Enable the integrated version of xwinclip. Do not use in # conjunction with the xwinclip program. # -depth bits_per_pixel # Specify the screen depth to run at (in bits per pixel) using a # DirectDraw-based engine in conjunction with the -fullscreen # option, ignored if the -fullscreen option is not specified. # By default, you will be using a DirectDraw based engine on any # system that supports it. # -unixkill # Trap Ctrl+Alt+Backspace as a server shutdown key combination. # -nounixkill # Disable Ctrl+Alt+Backspace as a server shutdown key combination (default). # Example: # XWin -unixkill -screen 0 -screen 1 -screen 2 -nounixkill # Screens 0 and 1 will allow Ctrl+Alt+Backspace, but screen 2 will not. # -winkill # Trap Alt+F4 as a server shutdown key combination (default). # -nowinkill # Disable Alt+F4 as a server shutdown key combination. # -scrollbars # Enable resizing of the server display window. Do not use in conjunction # with -multiwindow nor with -rootless. # -nodecoration # Draw the server root window without a title bar or border. # Do not use with -mutliwindow nor with -rootless. # -lesspointer # Hide the Windows mouse cursor anytime it is over any part of the # window, even if Cygwin/X is not the window with the focus. # -refresh rate_in_Hz # Specify a refresh rate to use when used with the -fullscreen option. # -trayicon # Enable the tray icon (default). # -notrayicon # Disable the tray icon. # Example: # XWin -notrayicon -screen 0 -screen 1 -screen 2 -trayicon # Screens 0 and 1 will not have tray icons, but screen 2 will. # -emulate3buttons [timeout] # Emulate 3 button mouse with an optional timeout in milliseconds. # -xf86config # Specify an XF86Config-style configuration file. # -keyboard # Specify a keyboard device from the configuration file. # # Startup the programs # # Startup the X Server with the integrated Windows-based window manager. # WARNING: Do not use 'xwinclip' in conjunction with the ``-clipboard'' # command-line parameter for XWin. Doing so would start two clipboard # managers, which is never supposed to happen. #XWin -multiwindow -clipboard -silent-dup-error set -x if [ $1 = 1 ] ; then XWin.exe -ac -clipboard -nodecoration \ -screen 0 1280x1024+1280+0 \ -terminate xterm fi if [ $1 = 3 ] ; then XWin.exe -ac -clipboard -nodecoration \ -screen 0 1280x1024+1280+-1024 \ -screen 1 1280x1024+1280+0 \ -screen 2 1280x1024+2560+0 \ -terminate fi if [ $1 = 5 ] ; then XWin.exe -ac -clipboard -nodecoration \ -screen 0 1280x1024+1280+-1024 \ -screen 1 1280x1024+1280+0 \ -screen 2 1280x1024+2560+0 \ -screen 3 1280x1024+2560+-1024 \ -screen 4 1280x1024+0+-1024 \ -terminate fi sleep 5 # Startup an xterm,
Re: scroll
On Thu, 6 Sep 2007, Reid Thompson wrote: you may prefer rxvt over xterm the options are pretty much the same Some of the options are (for scrolling - yes). Font-switching is different for instance. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [patch] inline __getreent in newlib
Brian Dessent wrote:
Done. I added the following comment to config.h to hopefully clarify
the situation:
/* The following provides an inline version of __getreent() for newlib,
which will be used throughout the library whereever there is a _r
version of a function that takes _REENT. This saves the overhead
of a function call for what amounts to a simple computation.
The definition below is essentially equivalent to the one in cygtls.h
(_my_tls.local_clib) however it uses a fixed precomputed
offset rather than dereferencing a field of a structure.
Including tlsoffets.h here in order to get this constant offset
tls_local_clib is a bit of a hack, but the alternative would require
dragging the entire definition of struct _cygtls (a large and complex
Cygwin internal data structure) into newlib. The machinery to
compute these offsets already exists for the sake of gendef so
we might as well just use it here. */
Turns out that sys/config.h includes cygwin/config.h, which leads to
this breakage when the winsup headers are installed in the system
location:
$ echo #include math.h | gcc -x c -
In file included from /usr/include/sys/config.h:180,
from /usr/include/_ansi.h:16,
from /usr/include/sys/reent.h:13,
from /usr/include/math.h:5,
from stdin:1:
/usr/include/cygwin/config.h:22:27: ../tlsoffsets.h: No such file or
directory
Attached patch fixes the situation by only exposing this when
_COMPILING_NEWLIB. Ok?
Brian2007-09-07 Brian Dessent [EMAIL PROTECTED]
* include/cygwin/config.h: Conditionalize inline __getreent()
definition on _COMPILING_NEWLIB.
Index: include/cygwin/config.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/config.h,v
retrieving revision 1.6
diff -u -p -r1.6 config.h
--- include/cygwin/config.h 7 Sep 2007 00:44:27 - 1.6
+++ include/cygwin/config.h 7 Sep 2007 23:15:23 -
@@ -37,9 +37,11 @@ extern C {
compute these offsets already exists for the sake of gendef so
we might as well just use it here. */
+#ifdef _COMPILING_NEWLIB
#include ../tlsoffsets.h
extern char *_tlsbase __asm__ (%fs:4);
#define __getreent() (struct _reent *)(_tlsbase + tls_local_clib)
+#endif /* _COMPILING_NEWLIB */
#define __FILENAME_MAX__ (260 - 1 /* NUL */)
#define _READ_WRITE_RETURN_TYPE _ssize_t
Re: [patch] inline __getreent in newlib
On Fri, Sep 07, 2007 at 04:19:12PM -0700, Brian Dessent wrote: Brian Dessent wrote: Done. I added the following comment to config.h to hopefully clarify the situation: /* The following provides an inline version of __getreent() for newlib, which will be used throughout the library whereever there is a _r version of a function that takes _REENT. This saves the overhead of a function call for what amounts to a simple computation. The definition below is essentially equivalent to the one in cygtls.h (_my_tls.local_clib) however it uses a fixed precomputed offset rather than dereferencing a field of a structure. Including tlsoffets.h here in order to get this constant offset tls_local_clib is a bit of a hack, but the alternative would require dragging the entire definition of struct _cygtls (a large and complex Cygwin internal data structure) into newlib. The machinery to compute these offsets already exists for the sake of gendef so we might as well just use it here. */ Turns out that sys/config.h includes cygwin/config.h, which leads to this breakage when the winsup headers are installed in the system location: $ echo #include math.h | gcc -x c - In file included from /usr/include/sys/config.h:180, from /usr/include/_ansi.h:16, from /usr/include/sys/reent.h:13, from /usr/include/math.h:5, from stdin:1: /usr/include/cygwin/config.h:22:27: ../tlsoffsets.h: No such file or directory Attached patch fixes the situation by only exposing this when _COMPILING_NEWLIB. Ok? Yes. Thanks. cgf
RE: Installation problem with cygintl-8.dll
On 07 September 2007 15:17, Rupert Young wrote: Hi, I downloaded the cygwin files onto a local directory on one machine, confirming that libintl8 was listed in the packages. I then moved, with a memory stick, the files to a PC without internet access and installed. But when I try to start cygwin I get the error, Application failed to start because cygintl-8.dll was not found. Reinstalling application may fix this problem. Also during install libintl8 is not listed. Any idea what I am doing wrong? Both machines are XP. Probably a glitch during installation, try re-running setup.exe in setup from local package directory mode and just clicking all the way through the various screens, setup should just fix up anything missing from the current install choices. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygwin/xemacs marking a buffer as read-only
I am changing the subject here because this problem is cygwin/xemacs-specific only, so it has nothing to do with smb permissions because I can touch and edit the same file with nano and save properly. Same with vi. It's entirely xemacs. I've attached my config, per request. -Original Message- From: Igor Peshansky [ mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 7:20 PM To: Joseph Koenig Cc: cygwin@cygwin.com Subject: Re: Passing domain credentials for a non-domain machine (similar to mapping drives through the Windows shell) On Wed, 5 Sep 2007, Joseph Koenig wrote: I have a desktop that I use to access a share with domain credentials despite not being on domain. So when I map a drive, I map it under domain\user and give it the password. This drive is mapped as Z. When I use cygwin to work on those files, it does not inherit the permissions that I mapped the network drive under and instead insists on using my local windows user and password (generated with mkpasswd) rather than what I mapped Z as. You want to add smbntsec to your CYGWIN environment variable. See http://cygwin.com/cygwin-ug-net/using-cygwinenv.html for details. Is there an easy way to manually edit the /etc/passwd file or change how cygwin reads the mapped volume to get it to use the same permissions that the windows shell is using? You'll also want to use mkpasswd -d /etc/passwd to get domain user information into it, and possibly mkgroup -d /etc/group (notice the double to append). (I searched the archives for thisI'm sure it's been answered but I couldn't find anything - I apologize) It also helps to read and follow Problem reports: http://cygwin.com/problems.html in particular the bit about attaching the output of cygcheck -svr. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Dave Korn wrote: Right, so IOW, the SEH support does all the required unwinding for us. Ultimately I guess that's the only solution that's going to be both complete and correct. (The only other thing I could even imagine would be some kind of hideous .pdb abuse using the M$ official symbol files to extract the frame and FPO information for frames in API functions...) Well, assuming that none of these foreign frames do any kind of -fomit-frame-pointer style optimizations, it should be possible to implement a fallback unwinder that simply ignores the frame and advances one frame up and resumes the table-based unwinding. And that's what (I thought) the recent w32-unwind.h contribution in 4.3 does, but I could be wrong. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Installation problem with cygintl-8.dll
Hi, I downloaded the cygwin files onto a local directory on one machine, confirming that libintl8 was listed in the packages. I then moved, with a memory stick, the files to a PC without internet access and installed. But when I try to start cygwin I get the error, Application failed to start because cygintl-8.dll was not found. Reinstalling application may fix this problem. Also during install libintl8 is not listed. Any idea what I am doing wrong? Both machines are XP. Regards, Rupert Young http://www.mobiletravelogue.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Brian Dessent wrote: You might argue that most people doing Win32 GUI stuff use MinGW, but a lot of them use Cygwin with -mno-cygwin which is MinGW with Cygwin build tools, a very convenient combination. And we can't offer a DW2 Cygwin gcc that uses SJLJ for -mno-cygwin as they are really both the same back-end just with different headers and runtimes. Here I meant to add that of course we have discussed deprecating -mno-cygwin and offering a real MinGW cross in its place, which would have its own back-end, and thus could have a different exception handling model. But by the time you've done all that, you might as well just package a separate gcc named gcc-dw2 or whatever and have them both installable in parallel, to please everybody. This is what Danny did with his 4.2 MinGW releases. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Slowness problem due to sjlj-exceptions for Octave
On 07 September 2007 13:41, Brian Dessent wrote: Anthony Heading wrote: Even if you catch the exception before it plummets through the Windows API? Well sure, but that's not realistic. The entire windowing engine is based on callbacks so it's unavoidable that there will be foreign frames. Does anyone know how MSVC handles unwinding through API frames? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Help needed with Big List of Dodgy Apps
Jim Kleckner wrote: Dave Korn wrote: [...] I'm adding code to cygcheck to detect whether any of the software that has been known at some time to cause these kinds of problems are installed on the target system being cygchecked. [...] Do you think a tester for API sanity is possible? i.e. make some known good calls and assert their return values or some such. Is there a common way that the badly designed hooking dlls cause problems or is each one quite different? Yes, this would be very useful alone or in combination: Detected current or previous Frobulator AV installation: Some versions have been known to interfere with Cygwin. Checking for known problems caused by this software... No known interferences have not been detected, although if you run into any of the following symptoms, you should start by *completely uninstalling* the suspect software and trying again (simply disabling it will likely not correct the problem): ... The problem with an Embedded Big List of Dodgy Apps is that any software that automatically updates itself could at any time suddenly start or stop interfering. Warning: you are running Windows, so it is likely that there is at least one Dodgy App hanging around somewhere. Please reboot and reinstall everything. gsw Every program has at least one bug and can be shortened by at least one instruction - from which, by induction, it is evident that every program can be reduced to one instruction that does not work. - Ken Arnold -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Anthony Heading wrote:
Even if you catch the exception before it plummets through the
Windows API?
Well sure, but that's not realistic. The entire windowing engine is
based on callbacks so it's unavoidable that there will be foreign
frames.
It seems clear I am not understanding something
that you're taking as an obvious truth. So let me try to state
my assumptions in case they're wrong:
Here is the basic skeleton of any windows GUI app, vastly simplified:
int WINAPI WinMain(...)
{
WNDCLASS wc;
MSG msg;
wc.lpszClassName = SomeClassName;
wc.lpfnWndProc = WndProc;
...
RegisterClass(wc);
HWND hwnd = CreateWindow (SomeClassName, ...);
ShowWindow(hwnd, ...);
// the message pump:
while (GetMessage(msg, NULL, 0, 0))
{
TranslateMessage(msg);
DispatchMessage(msg);
}
}
LRESULT CALLBACK
WndProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
switch (uiMsg)
{
case WM_CREATE:
// logic for OnCreate
case WM_SIZE:
// handle resizing
case WM_DESTROY:
// etc
case WM_PAINT:
// repaint myself
...
}
return DefWindowProc (...);
}
All of the actual processing of all window events happens through
messages passed to WndProc, but WndProc is never directly called by user
code. So if you want to communicate information between the window
procedure and the main function (such as: bad error happened, we need to
bail!) you wrap the message pump with a try/catch and throw from the
WndProc.
1) The Dwarf unwinder only needs to understand the frames that it
is considering unwinding. If an exception is thrown and caught
within a contiguous sequence of gcc frames, it doesn't matter
what strange or foreign structures are deeper in the stack,
because the unwinder never sees them.
Completely true, but unrealistic.
2) It's necessary or prudent to catch gcc exceptions before they
fall into windows callback code. I've never tried throwing a
g++ exception in a winproc handler and seeing if it makes
an express journey through user32.dll and back to the message
loop; but even if it seemed to work I'd be wary that windows
cleanup was being missed.
The problem is the WndProc is never called directly by the user, so by
definition when the unwinder looks at the next frame up it will be
inside the operating system/window manager somewhere.
I don't know how many users it would affect to simply decree thou may
not throw from inside a WndProc but I'm positive it would be nonzero --
this is not an obscure corner case. You might argue that most people
doing Win32 GUI stuff use MinGW, but a lot of them use Cygwin with
-mno-cygwin which is MinGW with Cygwin build tools, a very convenient
combination. And we can't offer a DW2 Cygwin gcc that uses SJLJ for
-mno-cygwin as they are really both the same back-end just with
different headers and runtimes. (Again, our own setup.exe is a prime
example.)
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Slowness problem due to sjlj-exceptions for Octave
On 07 September 2007 15:19, Brian Dessent wrote: Dave Korn wrote: Right, so IOW, the SEH support does all the required unwinding for us. Ultimately I guess that's the only solution that's going to be both complete and correct. (The only other thing I could even imagine would be some kind of hideous .pdb abuse using the M$ official symbol files to extract the frame and FPO information for frames in API functions...) Well, assuming that none of these foreign frames do any kind of -fomit-frame-pointer style optimizations, IIRC every MS win32 API dll (user32, kernel32, gdi32 etc.) does absolutely masses of FPO, so we're probably no-go there. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
On Fri, Sep 07, 2007 at 03:51:09AM -0300, Luiz Portella wrote: Hi, Saluton, -- Pedro Alves skribis je Tue, 21 Aug 2007 03:28:42 -0700 I just downloaded the source and compiled it, *without changing anything*, and the resulting binary worked without problems. I have the same problem about lastest mutt on XP. I get the source, and at /usr/src/mutt-1.4.2.2-1/ I run './configure ...', it works after many and lib both gcc instalations. http://cygwin.com/ml/cygwin/2007-08/msg00658.html But 'make install' get the bottom error No one has asked anyone to build mutt from source. That is a last resort in debugging problems and it wasn't required in this case. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Slowness problem due to sjlj-exceptions for Octave
On 07 September 2007 14:44, Brian Dessent wrote: Dave Korn wrote: Does anyone know how MSVC handles unwinding through API frames? MSVC implements C++ exception handling with SEH. And there is/was a GSoC project to port SEH to gcc, but I don't know if it went anywhere. Right, so IOW, the SEH support does all the required unwinding for us. Ultimately I guess that's the only solution that's going to be both complete and correct. (The only other thing I could even imagine would be some kind of hideous .pdb abuse using the M$ official symbol files to extract the frame and FPO information for frames in API functions...) cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Webdav cadaver: script possible?
Hi, with the ugly sounding but nice Cygwin tool cadaver (a command line Webdav client, like ftp) I would like to automatically download some files from the Webdav server to my local drive. However, in contrast to for example lftp, I don't see a way how to do the few commands automatically. For example, until now I've to do these steps: cadaver https://my_webdav.site.com this asks for username and password, then enters cadaver's command mode there I've to enter: * mget the_files * quit In case there's no way to use a script, would it be possible to somehow give all the command lines to the console which runs the cadaver program? Thanks. -ric -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help needed with Big List of Dodgy Apps
Jim Kleckner wrote: Dave Korn wrote: [...] I'm adding code to cygcheck to detect whether any of the software that has been known at some time to cause these kinds of problems are installed on the target system being cygchecked. [...] Do you think a tester for API sanity is possible? i.e. make some known good calls and assert their return values or some such. Is there a common way that the badly designed hooking dlls cause problems or is each one quite different? Yes, this would be very useful alone or in combination: Detected current or previous Frobulator AV installation: Some versions have been known to interfere with Cygwin. Checking for known problems caused by this software... No known interferences have not been detected, although if you run into any of the following symptoms, you should start by *completely uninstalling* the suspect software and trying again (simply disabling it will likely not correct the problem): ... The problem with an Embedded Big List of Dodgy Apps is that any software that automatically updates itself could at any time suddenly start or stop interfering. Warning: you are running Windows, so it is likely that there is at least one Dodgy App hanging around somewhere. Please reboot and reinstall everything. Even without having looked at the Cygwin lib sources, I would have to say that the idea sounds useless, if the app is linked against a library, or library wrapper, that is constantly being patched. The Linux malloc man page, near the bottom, describes the MALLOC_CHECK_ environment variable. If you have it handy, you might look at it. This mechanism is the hook into the library for debugging tools like cfence, and other memory checkers. Any check for apps that might have been shoehorned into the environment also need to check for events like the signals that the Windows DLLs issue. I'm told that Windows, for example, traps SIGSEGV, while UNIX, of course, does not. UNIX apps that can't cope with their environment, because of some spurious event, terminate with a core dump. Without that sort of information, the testing methods would be too random and slipshod to make any sort of diagnoses. Not trying to be too cynical about this. But I'd have a look at the Cygwin DLLs and have a go at this kind of debugging tool, if anyone is interested. Regards Ctalk Home Page: http://ctalk-lang.sourceforge.net/. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood *Revisited*
Sorry to bring back this old thread back. Is there anyone that can explain a fix for this problem. I've only been using rsync/cygwin/on ssh for about 3 weeks, so please explain in dummy terms. It's the exact same problem mentioned here: http://cygwin.com/ml/cygwin/2006-04/msg00792.html -- - Original Message - From: René Berber Steven Hartland wrote: Just to back this up, we cant get basic rsync to run reliably using cygwin either. The command being tested is run from a FreeBSD box with the source being a cygwin box using cygwin 1.5.19-4: rsync -av cygwin1:/testdir/ /testdir/ The result is it will randomly hang on a file, no output / error returned just stops. [snip] tcsh6.14.00-5 OK While testing is csh involved? Your description above is very close to a problem with cvs reported and solved recently by Jay Abel. In short, tcsh at the receiving end is changing \r\n to \n inside binary files, so the receiving process waits for the expected bytes but it receives less. tcsh is the default shell on FreeBSD which is the recieving end in this test yes but I'm a little confused how the shell could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD to Windows SFU doesnt have this issue so something specific to tcsh on cygwin? An example of this failure is: [log] rsync -av --progress cygwin1:/testdir/ /testdir/ receiving file list ... 1705 files to consider created directory testdir / bf2_w32ded.exe 0 0%0.00kB/s0:00:00 ***Hung here*** ^CKilled by signal 2.0.00kB/s0:00:00 rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(242) [receiver] rsync error: unexplained error (code 255) at rsync.c(242) [generator] [/log] - Brett Serkez wrote: After running into the hang trying to use rsync over ssh on Cygwin, reported on this mailing list, but with no resolution other than use of daemon mode, I tracked down the problem. I have rsync working over ssh on Cygwin. The hang is occuring when rsync is attempting to exchange protocol version numbers, it writes its version and then hangs waiting endlessly for a reply. The ssh process is detached, and apparently not diretly connected to rsync, as it is an orphan, owned by process 1. The ssh process never even gets as far as attempting network access and rsync never does anything of value. Not defining HAVE_SOCKETPAIR in the make configuration is enough to use pipe() vs. socketpair(), which is enough for rsync to run using ssh, just as it does on UNIX. While I've not done extensive testing, I've used it enough to believe it is working as designed/intended. The source file that is effected by the above change (primarily) is util.c in function: fd_pair(): #ifdef HAVE_SOCKETPAIR ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd); #else ret = pipe(fd); #endif While use of socketpair() may be a better method, use of pipe() does work and I'd request that the rsync package maintainer please rebuild the package with this build option change and reissue the package so all can benefit. Perhaps socketpair() can be used with a future release of Cygwin? Thank you, Brett Brett C. Serkez, Techie -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
On 2007-09-07 13:37Z, Dave Korn wrote: Does anyone know how MSVC handles unwinding through API frames? With SEH: http://www.howzatt.demon.co.uk/articles/oct04.html http://www.microsoft.com/msj/0197/Exception/Exception.aspx -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Dave Korn wrote: Does anyone know how MSVC handles unwinding through API frames? MSVC implements C++ exception handling with SEH. And there is/was a GSoC project to port SEH to gcc, but I don't know if it went anywhere. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Dave Korn wrote: IIRC every MS win32 API dll (user32, kernel32, gdi32 etc.) does absolutely masses of FPO, so we're probably no-go there. Hey! Here's the first documented case of Vista doing something useful: FPO was enabled for all Windows binaries in NT 3.51, but was turned off for Windows binaries in Vista because it was no longer necessary - machines got sufficiently faster since 1995 that the performance improvements that were achieved by FPO weren't sufficient to counter the pain in debugging and analysis that FPO caused. According to Larry Osterman, at least. http://blogs.msdn.com/larryosterman/archive/2007/03/12/fpo.aspx Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
-- Christopher Faylor skribis: http://cygwin.com/ml/cygwin/2007-08/msg00658.html Ja! Now it is working fine! Thanks a lot, -- Luiz Portella Edite seu livro: http://www.pentuvio.com/eldoni.php -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
opendir() system call
hi, I wanted to ask if system calls of unix like opendir(),readir() work in cygwin.I tried them in a simple program but it didn't work.The stack dump was- Exception: STATUS_ACCESS_VIOLATION at eip=610DE9A1 eax= ebx= ecx= edx=0029 esi=0001 edi=0029 ebp=0022B048 esp=0022B044 program=C:\cygwin\home\sudeep\a.exe, pid 2240, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022B048 610DE9A1 (0029, 0022B5EE, 00402014, 0001) 0022CC68 610E1A1B (0022D008, 611010E8, 0040200F, 0022CCBC) 0022CC88 610E4E78 (611010E8, 0040200F, 0022CCB4, 61004A0E) 0022CCA8 610EEA55 (0040200F, 72BD, 0029, 00664054) 0022CCE8 61092D88 (0001, 61169690, 00660090, 0022CC70) 0022CD98 61006198 (, 0022CDD0, 61005510, 0022CDD0) 61005510 61004416 (009C, A02404C7, E8611001, FF48) 14668 [main] a 2240 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) please help me Digant Goyal, Indore, India. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin compliation crash when uninstalling the old version of bash
On 2007-0820 06:07:47, Eric Blake wrote: According to wei on 8/19/2007 3:09 PM: It's a popup box from setup.exe. I also attached the cygcheck.out in the email And what did the popup say? Nothing in your cygcheck output is jumping out at me as unusual, but without knowing what the crash said, I don't know the full picture. having this problem too... not used to windows, using cygwin at office to be able to do some work without having to learn an other operating system. the popup is the usual microsoft notification we lost all of your data, help us to fix our bugs [ok] more literally: start cygwin setup, get at select packages, click on [view] until I get the partial view, only package to update is bash, from current 3.2.17-15 to new 3.2.25-16, click on [volgende] ([next] but in dutch), next is this mostly dutch popup (I work for a dutch company): text in window decoration: setup.exe white upper frame saying: In setup.exe is een fout opgetreden en moet worden afgesloten. Onze excuses voor dit ongemak. on the right hand side there the icon of setup.exe. then the lower part of the popup says: U was bezig met een bewerking. Deze gegevens zijn mogelijk verloren gegaan. Vertel Microsoft over dit probleem. We have created an error report that you can send to us. We will treat this report as confidential and anonymous. Als u de inhoud van dit foutenrapport wilt weergeven, _klikt u hier._ [Fouten opsporen] [Rapport verzenden] [Niet verzenden] two files are generated at the same time, put in my Local\ Settings/Temp directory: -rw-rw-rw- 1 Mario Frasca root 1280643 09-07 09:09 9227207.dmp -rw-rw-rw- 1 Mario Frasca root 8742 09-07 09:09 707a_appcompat.txt they are removed when I click on [Niet verzenden]. what do you suggest? I already tried to reboot the system and do the update as first thing, but setup.exe crashes all the same... by the way, I'm using Setup.exe version 2.573.2.2 thanks, Mario -- Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read. -- Groucho Marx. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
Hi, Saluton, -- Pedro Alves skribis je Tue, 21 Aug 2007 03:28:42 -0700 I just downloaded the source and compiled it, *without changing anything*, and the resulting binary worked without problems. I have the same problem about lastest mutt on XP. I get the source, and at /usr/src/mutt-1.4.2.2-1/ I run './configure ...', it works after many and lib both gcc instalations. But 'make install' get the bottom error The final binary also has only 526kb, much smaller than the one I got from the same binary package. (I was expecting +- the same output) the binary package is 1519kb. Hope it helps :( the error: ... make[2]: Nothing to be done for all'. make[2]: Leaving directory '/usr/src/mutt-1.4.2.2-1/intl' Making all in doc make[2]: Entering directory '/usr/src/mutt-1.4.2.2-1/doc' ##test -f manual.html || make manual.html || cp ./manual*.html ./ cp ./manual*.html ./ cp: './manual-1.html' and './manual-1.html' are the same file cp: './manual-2.html' and './manual-2.html' are the same file cp: './manual-3.html' and './manual-3.html' are the same file cp: './manual-4.html' and './manual-4.html' are the same file cp: './manual-5.html' and './manual-5.html' are the same file cp: './manual-6.html' and './manual-6.html' are the same file cp: './manual-7.html' and './manual-7.htm' are the same file cp: './manual.html' and './manual.html' are the same file make[2]: *** [try-html] Error 1 make[2]: Leaving directory '/usr/src/mutt-1.4.2.2-1/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/usr/src/mutt-1.4.2.2-1' make: *** [all] Error 2 How do? Thanks, -- Luiz Portella Edite seu livro: http://www.pentuvio.com/eldoni.php -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: opendir() system call
On 07 September 2007 15:41, digant goyal wrote: I wanted to ask if system calls of unix like opendir(),readir() work in cygwin. Yes, they work fine, that's the whole point of cygwin. I tried them in a simple program but it didn't work. Most likely a bug in your code. The stack dump was- No use without knowing what version of the cygwin dll you have installed! Can you reduce your code to one very simple testcase that just shows an attempt to call opendir and how it fails? Something that everyone else could just compile and run on our machines without having to go to great lengths? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: zsh-4.3.4-1
zzapper wrote: I'm getting the following errors (this is actually for 4.3.2 which I tried withot success to roll back to) 3 [main] zsh 5904 C:\cygwin\bin\zsh.exe: *** fatal error - unable to remap C:\cygwin\lib\zsh\4.3.2\zsh\complete.dll to same address as parent(0x35) != 0x39 I've tried uninstall/reinstall, rebaseall, restarts etc. If anyone has no problems with 4.3.4, pls let me know I had a similar problem but rebaseall workwed for me. RM -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24: sshd immediately disconnects upon receiving a connection
So going off what Jim noticed about the faulty install of cygwin on Vista, I was able to install cygwin correctly while in Safe Mode with Networking. I installed the sshd service in Safe mode as well but you cannot start it up until you reboot back into full mode. But then it seems to work just fine as a service. As to what service might be the cause of the problem when trying to install cygwin in Normal Windows mode, I tried narrowing down the services that were started in Normal mode but stopped in Safe mode. As you can guess there were many of them. I made a list of them and started shutting them off 2-3 at a time and deleting cygwin and installing it. I got most of the services stopped and it was still reproducing the bash.exe.stackdump every time. The following services I could not stop: Group Policy Client (maybe it was a GP problem? although it's a local computer account) Security Accounts Manager Windows Driver Foundation - User-mode Driver Framework Windows Error Reporting Service The following services seemed to restart on their own once I stopped them: COM+ Event system Windows Multimedia Instrumentation Windows Search Program Compatibility Assistant Service So any of the above services could be the culprit or more likely there might have been some other proprietary service causing the problem. The good thing is the solution seemed to be: installing Cygwin and sshd from Safe mode with networking. On that same machine, I tried removing cygwin and reinstalling the base packages. Although you can get a cygwin.bat to run, each of the postinstall scripts gives an error when run. So it is not likely that it is a clean install. Has anyone seen these kinds of errors in /var/log/setup.log.full ? I've tried a host of chmod 777 and chgrp Users and chgrp Administrators attempts but always seem to get the bash.exe.stackdump in / Could this be a result of using RDP and remote sessions? Could it be that it is a dual core AMD? I don't have direct access to the computer (2 hours by plane). Thanks - Jim === 2007/09/05 16:41:02 Starting cygwin install, version 2.573.2.2 ... 2007/09/05 16:42:05 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/terminfo.sh 16 [unknown (0xC90)] bash 3692 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 227131 [unknown (0xC90)] bash 3692 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 2007/09/05 16:42:16 abnormal exit: exit code=35584 2007/09/05 16:42:16 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/00bash.sh 6 [unknown (0xE18)] bash 3680 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 124434 [unknown (0xE18)] bash 3680 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 2007/09/05 16:42:22 abnormal exit: exit code=35584 -- Jeremy K. Truax [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help needed with Big List of Dodgy Apps
On Fri, Sep 07, 2007 at 09:55:26AM -0400, Robert Kiesling wrote: Jim Kleckner wrote: Dave Korn wrote: [...] I'm adding code to cygcheck to detect whether any of the software that has been known at some time to cause these kinds of problems are installed on the target system being cygchecked. [...] Do you think a tester for API sanity is possible? i.e. make some known good calls and assert their return values or some such. Is there a common way that the badly designed hooking dlls cause problems or is each one quite different? Yes, this would be very useful alone or in combination: Detected current or previous Frobulator AV installation: Some versions have been known to interfere with Cygwin. Checking for known problems caused by this software... No known interferences have not been detected, although if you run into any of the following symptoms, you should start by *completely uninstalling* the suspect software and trying again (simply disabling it will likely not correct the problem): ... The problem with an Embedded Big List of Dodgy Apps is that any software that automatically updates itself could at any time suddenly start or stop interfering. Warning: you are running Windows, so it is likely that there is at least one Dodgy App hanging around somewhere. Please reboot and reinstall everything. Even without having looked at the Cygwin lib sources, I would have to say that the idea sounds useless, if the app is linked against a library, or library wrapper, that is constantly being patched. The Linux malloc man page, near the bottom, describes the MALLOC_CHECK_ environment variable. If you have it handy, you might look at it. This mechanism is the hook into the library for debugging tools like cfence, and other memory checkers. Any check for apps that might have been shoehorned into the environment also need to check for events like the signals that the Windows DLLs issue. I'm told that Windows, for example, traps SIGSEGV, while UNIX, of course, does not. UNIX apps that can't cope with their environment, because of some spurious event, terminate with a core dump. ? I don't know what this means but Windows has the equivalent of SIGSEGV. Without that sort of information, the testing methods would be too random and slipshod to make any sort of diagnoses. Not trying to be too cynical about this. But I'd have a look at the Cygwin DLLs and have a go at this kind of debugging tool, if anyone is interested. Implementing something on the order of MALLOC_CHECK_ would not address this problem. Cygwin already has hooks like this but they would not help here. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood *Revisited*
On Fri, Sep 07, 2007 at 09:57:13AM -0500, Jonathan Hurd wrote: Sorry to bring back this old thread back. Is there anyone that can explain a fix for this problem. I've only been using rsync/cygwin/on ssh for about 3 weeks, so please explain in dummy terms. It's easy to explain - There is no fix yet. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: mutt-1.4.2.2-2
I've made a new version of 'mutt' available for installation. Mutt is a text mode mail user agent. This version uses the shared version of libiconv which reduces the size of mutt.exe dramatically. More importantly, it fixes the problems that were reported with FAT32 filesystems: http://sourceware.org/ml/cygwin/2007-08/threads.html#00549 For a listing of the files this package contains, see http://cygwin.com/packages/mutt . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and keep clicking Next. If you have questions or comments, please send them to the Cygwin mailing list. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] 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. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood *Revisited*
It just doesn't make sense how this can work perfectly for about 2 weeks, and then out of nowhere all sync's start to hang with transfer over a certain amount. Christopher Faylor wrote: On Fri, Sep 07, 2007 at 09:57:13AM -0500, Jonathan Hurd wrote: Sorry to bring back this old thread back. Is there anyone that can explain a fix for this problem. I've only been using rsync/cygwin/on ssh for about 3 weeks, so please explain in dummy terms. It's easy to explain - There is no fix yet. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
I just want to clarify... Can you give a dump of these two commands: echo $PATH gcc -v from a cygwin command line... I suspect the reason all along is that the REAL minGW is trying to ignore cygwin all together, but in the process, cygwin is seeing a 'gcc' binary earlier in its PATH so it uses that -- the official minGW binary. MinGW-official has nothing to do with cygwin Here... thats why I asked... (pause) On cygwin [EMAIL PROTECTED] ~ $ echo $PATH /usr/local/bin:/usr/bin:/usr/bin:/usr/X11R6/bin:/usr/bin:/cygdrive/c/ WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/WBEM: /cygdrive/c/Program Files/Microsoft SQL Server/90/Tools/binn/:/cygdrive/d/usr/Tatsu/ program/ScriptTools:/cygdrive/c/Program Files/ckw:/cygdrive/c/Program Files/gawk-mbcs-win32-20070407:/cygdrive/c/Program Files/wscite:/ cygdrive/c/Program Files/Hidemaru:/cygdrive/c/Program Files/gp420win32 /gnuplot/bin:/cygdrive/c/Program Files/md5command:/usr/lib/lapack $ gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/ configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/ etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man -- infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java, objc --enable-nls --without-included-gettext --enable-version-specific -runtime-libs --without-x --enable-libgcj --disable-java-awt --with- system-zlib --enable-interpreter --disable-libgcj-debug --enable- threads=posix --enable-java-gc=boehm --disable-win32-registry --enable -sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx- debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) $ /opt/gcc-3.4.4d/bin/gcc -v bash: /opt/gcc-3.4.4d/bin/gcc: No such file or directory $ /opt/octave-2.9.13/gcc-3.4.4d/bin/gcc -v Reading specs from /opt/octave-2.9.13/gcc-3.4.4d/lib/gcc/i686-pc- cygwin/3.4.4/specs Configured with: /home/gcc_s/gcc-3.4.4-3/gcc-3.4.4-3/configure -- disable-sjlj-exceptions --prefix=/opt/octave-2.9.13/gcc-3.4.4d Thread model: single gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Before octave ./confure, I set the following export CC='/opt/octave-2.9.13/gcc-3.4.4d/bin/gcc' export CXX='/opt/octave-2.9.13/gcc-3.4.4d/bin/g++' export F77='/opt/octave-2.9.13/gcc-3.4.4d/bin/g77' export CPPFLAGS='-I/opt/octave-2.9.13/gcc-3.4.4d/include -I/opt/octave -2.9.13/include' export LDFLAGS='-L/opt/octave-2.9.13/gcc-3.4.4d/lib -L/opt/octave-2.9. 13/lib' *** In /opt/octave-2.9.13/gcc-3.4.4d, the gcc prepared with --disable-sjlj -exceptions exist. ** On mingw (msys) $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/ WINDOWS/system32/WBEM:/c/Program Files/Microsoft SQL Server/90/Tools/ binn/:/d/usr/Tatsu/program/ScriptTools:/c/Program Files/ckw:/c/ Program Files/gawk-mbcs-win32-20070407:/c/Program Files/wscite:/c/ Program Files/Hidemaru:/c/Program Files/gp420win32/gnuplot/bin:/c/ Program Files/md5command:/GnuWin32/bin $ gcc -v Reading specs from c:/Programs/MinGW/bin/../lib/gcc/mingw32/3.4.2/ specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu- as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads -- disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32 -registry --disable-shared --enable-sjlj-exceptions --enable-libgcj -- disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj- debug --enable-interpreter --enable-hash-synchronization --enable- libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) /etc/fstab c:\Programs\MinGW /mingw C:\Programs\msys\1.0\local /usr/local C:\Programs\msys\1.0\include /usr/include C:\Programs\msys\1.0\lib /usr/lib C:\Programs\GnuWin32 /GnuWin32 D:\usr\Tatsu\mingwhome /home ** Native windows Path C:\Documents and Settings\Tatsupath PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\ Program Files\Mi crosoft SQL Server\90\Tools\binn\;D:\usr\Tatsu\program\ScriptTools;C: \Program Fi les\ckw;C:\Program Files\gawk-mbcs-win32-20070407;C:\Program Files\ wscite;C:\Pro gram Files\Hidemaru;C:\Program Files\gp420win32\gnuplot\bin;C:\ Program Files\md5 command I did not set PATH variable to the cygwin nor mingw(msys). Path to the cygwin or the mingw is set in starting batch files. Sincerely Tatsuro MATSUOKA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Ctrl-C will not kill a process started from cygwin shell
Hi, I'm sorry if this is an obvious question but I searched and couldn't find an obvious answer and wasn't sure what to search for... It seems that some processes I start from a cygwin shell start in the foreground - whereas if I start them from a cmd shell they start in the background. (I know I can append an but that's not the point here). One process I know of in particular is my favoured Micro Emacs editor (available at http://www.jasspa.com/). When this starts in the foreground from cygwin, even Ctrl-C will not kill the process. What determines this behavior and can I do anything about it. I ask because more importantly, I am running into issues running Maven tasks that do not return to the shell after completion. The only option available to be is to kill the entire cygwin shell. Please can someone explain what might be happening here, or point me at documentation on this subject. Thanks! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help needed with Big List of Dodgy Apps
On Fri, Sep 07, 2007 at 09:55:26AM -0400, Robert Kiesling wrote: Jim Kleckner wrote: Dave Korn wrote: [...] I'm adding code to cygcheck to detect whether any of the software that has been known at some time to cause these kinds of problems are installed on the target system being cygchecked. [...] Do you think a tester for API sanity is possible? i.e. make some known good calls and assert their return values or some such. Is there a common way that the badly designed hooking dlls cause problems or is each one quite different? Yes, this would be very useful alone or in combination: Detected current or previous Frobulator AV installation: Some versions have been known to interfere with Cygwin. Checking for known problems caused by this software... No known interferences have not been detected, although if you run into any of the following symptoms, you should start by *completely uninstalling* the suspect software and trying again (simply disabling it will likely not correct the problem): ... The problem with an Embedded Big List of Dodgy Apps is that any software that automatically updates itself could at any time suddenly start or stop interfering. Warning: you are running Windows, so it is likely that there is at least one Dodgy App hanging around somewhere. Please reboot and reinstall everything. Even without having looked at the Cygwin lib sources, I would have to say that the idea sounds useless, if the app is linked against a library, or library wrapper, that is constantly being patched. The Linux malloc man page, near the bottom, describes the MALLOC_CHECK_ environment variable. If you have it handy, you might look at it. This mechanism is the hook into the library for debugging tools like cfence, and other memory checkers. Any check for apps that might have been shoehorned into the environment also need to check for events like the signals that the Windows DLLs issue. I'm told that Windows, for example, traps SIGSEGV, while UNIX, of course, does not. UNIX apps that can't cope with their environment, because of some spurious event, terminate with a core dump. ? I don't know what this means but Windows has the equivalent of SIGSEGV. The signal is non-catchable by UNIX apps. That ability would be useful when malloc goes whizzing off into the video RAM, but the issue is almost always a bug somewhere else in the app. That is not to say that the system libraries are perfect, of course. Without that sort of information, the testing methods would be too random and slipshod to make any sort of diagnoses. Not trying to be too cynical about this. But I'd have a look at the Cygwin DLLs and have a go at this kind of debugging tool, if anyone is interested. Implementing something on the order of MALLOC_CHECK_ would not address this problem. Cygwin already has hooks like this but they would not help here. With the amount of code that comprises Cygwin, it might be useful not only for the people who maintain applications, but also when patching the libraries, to have a lower-level database of most frequently used library functions, and software failures that occur when using them, which might be a more useful set of data when porting or upgrading, as the software faults would seem to occur at the level of the library function calls, which it usually seems to be here. Regards Ctalk Home Page: http://ctalk-lang.sourceforge.net/. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync over ssh hang issue understood *Revisited*
Jonathan Hurd wrote: Christopher Faylor wrote: On Fri, Sep 07, 2007 at 09:57:13AM -0500, Jonathan Hurd wrote: Sorry to bring back this old thread back. Is there anyone that can explain a fix for this problem. I've only been using rsync/cygwin/on ssh for about 3 weeks, so please explain in dummy terms. It's easy to explain - There is no fix yet. It just doesn't make sense how this can work perfectly for about 2 weeks, and then out of nowhere all sync's start to hang with transfer over a certain amount. Never underestimate the power of luck. -- 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? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ctrl-C will not kill a process started from cygwin shell
Alex Worden wrote: Hi, I'm sorry if this is an obvious question but I searched and couldn't find an obvious answer and wasn't sure what to search for... It seems that some processes I start from a cygwin shell start in the foreground - whereas if I start them from a cmd shell they start in the background. (I know I can append an but that's not the point here). One process I know of in particular is my favoured Micro Emacs editor (available at http://www.jasspa.com/). When this starts in the foreground from cygwin, even Ctrl-C will not kill the process. What determines this behavior and can I do anything about it. I ask because more importantly, I am running into issues running Maven tasks that do not return to the shell after completion. The only option available to be is to kill the entire cygwin shell. Please can someone explain what might be happening here, or point me at documentation on this subject. You're much better off directing these kinds of questions to the provider of the package. Discussion of external packages is not wholly on-topic here. My WAG on your CTRL-C problems, based on lack of input about your environment, you don't have 'tty' in your CYGWIN environment variable. -- 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? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Dave Korn wrote: Right, so IOW, the SEH support does all the required unwinding for us. Ultimately I guess that's the only solution that's going to be both complete and correct. Well, that is essentially the solution MinGW is using now with SJLJ exceptions. MSVCRT's longjmp() is implemented using a SEH forced unwind. Brian Dessent writes: Well, assuming that none of these foreign frames do any kind of -fomit-frame-pointer style optimizations, it should be possible to implement a fallback unwinder that simply ignores the frame and advances one frame up and resumes the table-based unwinding. I thought about the possibilty mixing the two exception handling methods and having the MinGW try to unwind both the DWARF and SEH frames in parallel. Unfortnately, because they do use FPO, I think the best you can do is unwind DWARF frames until you get to the callback and then unwind SEH frames. I don't think there's anyway you can reliably pick up the DWARF frames again, and so it wouldn't be a better solution. And that's what (I thought) the recent w32-unwind.h contribution in 4.3 does, but I could be wrong. It looks like it's a crude hack for the specific problem of unwinding through signal handlers. It's dependent on both specific instruction sequences used in the operating system code that calls these handlers and the layout of their stack frames. I wouldn't be surprised if it doesn't work on Win9x, checked builds of Windows XP, Wine or in some other context that the author might not have tested it on. Ross Ridge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help needed with Big List of Dodgy Apps
Robert Kiesling wrote: ? I don't know what this means but Windows has the equivalent of SIGSEGV. The signal is non-catchable by UNIX apps. That ability would be useful when malloc goes whizzing off into the video RAM, but the issue is almost always a bug somewhere else in the app. That is not to say that the system libraries are perfect, of course. Um... I can catch SIGSEGV just fine in my UNIX apps. Or did you mean cygwin apps can't catch it? (Granted, I don't attempt to *recover* from a SEGV, just say hey, I got a SEGV and either exit() or abort().) -- Matthew Cannot read .sig now -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help needed with Big List of Dodgy Apps
On Fri, Sep 07, 2007 at 04:17:30PM -0500, Matthew Woehlke wrote: Robert Kiesling wrote: ? I don't know what this means but Windows has the equivalent of SIGSEGV. The signal is non-catchable by UNIX apps. That ability would be useful when malloc goes whizzing off into the video RAM, but the issue is almost always a bug somewhere else in the app. That is not to say that the system libraries are perfect, of course. Um... I can catch SIGSEGV just fine in my UNIX apps. Or did you mean cygwin apps can't catch it? (Granted, I don't attempt to *recover* from a SEGV, just say hey, I got a SEGV and either exit() or abort().) Cygwin can catch SIGSEGV just fine. So can Windows. I don't want to belabor the point but there isn't much that makes sense to me here, especially in context of the subject. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Slowness problem due to sjlj-exceptions for Octave
Hello Brian This is Tatsuro Matsuoka replying. Here I meant to add that of course we have discussed deprecating -mno-cygwin and offering a real MinGW cross in its place, which would have its own back-end, and thus could have a different exception handling model. But by the time you've done all that, you might as well just package a separate gcc named gcc-dw2 or whatever and have them both installable in parallel, to please everybody. This is what Danny did with his 4.2 MinGW releases. Brian To whom you wrote this message? To me? I am now using three different compliers on the cygwin. gcc-4.2.1 (only gcc, gfortran, g++). gcc-3.4.4-3 configured with '--disable-sjlj-exceptions' (only gcc, gfortran, g++) standard gcc-3.4.4-3 in cygwin package. Usually first I try gcc-4.2.1 because its optimizing ability is good. I have build the cvs version gnuplot, it works well and very fast. The building by gcc-4.2.1 sometimes fails. Second I use standard cygwin gcc complier. Because the ordinary programs do not use the unwind exceptions, the gcc configured with sjlj-exceptions has no slowness problem. It is favorable to use standard complier if it makes no slowness. In octave case, I am using the complier gcc-3.4.4-3 configured with '- -disable-sjlj-exceptions'. Building octave by standard complier, the slowness appears. Especially the interpreter speed slows very much. When most part of the program to be vectorized, the calculation speed is not so slow. But I have to use iteration or iterated estimation the function value inside octave (for example ODE solver) occurs, the slowness is not allowable. So I tried make octave by gcc configured with ?disable-sjlj-exception because I found the following thead. http://cygwin.com/ml/cygwin/2005-04/msg01072.html just package a separate gcc named gcc-dw2 or whatever and have them both installable in parallel, to please everybody. I install of course two my own GCCs placed at the different directories from the standard one. If the gcc-dw2 will be packaged, where is the suitable directory it will be placed. I think the directories where the standard complier used is to be avoided. Sincerely Tatsuro MATSUOKA -- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
what about (mutt) Maildir on Cygwin
Hi, I have problems with mutt and maildir on Cygwin: http://www.mail-archive.com/cygwin@cygwin.com/msg31457.html As soon as a new mail arrived in the main folder (inbox), I could not even close mutt properly. It always gives me the error rename file or folder does not exist (error=2) in the status bar. I read e-mails from 2003 about it: http://www.mail-archive.com/cygwin@cygwin.com/msg31967.html (Gary R. Van Sickle) Now is it fixed? en.wikipedia.org/wiki/Maildir at Windows Software say yes, but I don't get it. What package I need install? Thankful, -- Luiz Portella Edite seu livro: http://www.pentuvio.com/eldoni.php -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: what about (mutt) Maildir on Cygwin
Saluton, I find http://www.geocities.com/win32mutt/patches.html with http://www.geocities.com/win32mutt/patches/mutt-1.4.uen.win32.1.zip date 2002-07-03, for Mutt-1.4i. Who have it with the latest mutt? mutt-1.4.2.2-2 I get the patch, I guess make, make install, ... How I use it? :) Luiz -- Luiz Portella skribis: Hi, I have problems with mutt and maildir on Cygwin: http://www.mail-archive.com/cygwin@cygwin.com/msg31457.html As soon as a new mail arrived in the main folder (inbox), I could not even close mutt properly. It always gives me the error rename file or folder does not exist (error=2) in the status bar. I read e-mails from 2003 about it: http://www.mail-archive.com/cygwin@cygwin.com/msg31967.html (Gary R. Van Sickle) Now is it fixed? en.wikipedia.org/wiki/Maildir at Windows Software say yes, but I don't get it. What package I need install? Thankful, -- Luiz Portella Edite seu livro: http://www.pentuvio.com/eldoni.php -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: zsh-4.3.4-1
On Thu, 6 Sep 2007, zzapper wrote: An updated version of zsh (zsh-4.3.4-1) has been released and should be at a mirror near you real soon. Peter, (you may have already got this) I'm getting the following errors (this is actually for 4.3.2 which I tried withot success to roll back to) 3 [main] zsh 5904 C:\cygwin\bin\zsh.exe: *** fatal error - unable to remap C:\cygwin\lib\zsh\4.3.2\zsh\complete.dll to same address as parent(0x35) != 0x39 I've tried uninstall/reinstall, rebaseall, restarts etc. If anyone has no problems with 4.3.4, pls let me know Rebaes didn't fix it? Now that is strange. My own usage/testing of 4.3.4 did not have this problem. I think you'll have to send me your cygcheck output so I can try and repro your environment. BTW, my build/test env is still Win2k, so this might be an XP specific issue (if XP is what you are using :-). -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated: mutt-1.4.2.2-2
I've made a new version of 'mutt' available for installation. Mutt is a text mode mail user agent. This version uses the shared version of libiconv which reduces the size of mutt.exe dramatically. More importantly, it fixes the problems that were reported with FAT32 filesystems: http://sourceware.org/ml/cygwin/2007-08/threads.html#00549 For a listing of the files this package contains, see http://cygwin.com/packages/mutt . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and keep clicking Next. If you have questions or comments, please send them to the Cygwin mailing list. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] 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.
