Re: GCC4 status.
On Feb 24 00:27, Charles Wilson wrote:
Christopher Faylor wrote:
On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
Dave Korn wrote:
it's going to be a fairly non-standard
x-compiler in that it won't go into the usual $prefix/$target sysroot,
it's
going to look for headers and libs directly where they live under the
native
prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and
/lib/w32api,
and it's going to use the native 'as' and 'ld'. So it's going to be an
ugly
hybrid beast
Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
because we don't want two copies of w32api and mingw-runtime, or a
cross-ld/cross-as?
I think the maintenance headaches associated with an ugly hybrid beast
outweigh those other, tiny, costs...
I agree. I think we should relocate
relocate? But the regular cygwin gcc needs at least w32api, and that
location is hardcoded in its specs file. Which means that relocate
implies - respin gcc-3.4.4-999, and respin gcc-4.2.3. And it doesn't
really make sense for the cygwin-gcc specs to specify always look in
/usr/i686-pc-mingw32/include/[w32api]. Whuh, huh? *-mingw32?
It makes more sense to me that we have two different w32api packages:
the regular one that installs into /usr/[include|lib]/w32api, and a
mingw-cross-w32api that installs into
/usr/${mingw-triple}/[include|lib]/[w32api].
IMO it would be much easier to keep mingw and w32api in place and just
create matching symlinks in /usr/i686-pc-mingw32. This way you can
create a standard compiler *and* keep the include and lib files in
place. We can't move all of it out of the way anyway. We need at least
the mingw DLL in /bin since some Cygwin tools rely on it. And using
w32api headers and linking against Windows libs in Cygwin applications
might not be very POSIX compliant, but is necessary. Every Cygwin
application you link must be linked against kernel32.dll and friends.
There's also still a lot of Windows functionality we can't cover in
Cygwin. USB access as in libusb-win32 comes to mind.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [RFU-1.7] astyle-1.23-1
On Feb 23 14:27, Chris Sutcliffe wrote: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/astyle-1.23-1.tar.bz2 \ http://emergedesktop.org/cygwin/astyle-1.23-1-src.tar.bz2 Given the email from Corrina (I believe it was) a while back about ^^^ s/rrin/rinn/ influencing people to try the 1.7.0 release, I have not created any 1.5.x packages for this release (I don't have a 1.5.x install on my development box any more). Is this acceptable, or do I need to still create a 1.5.x release for this package? Nope. That's perfectly fine. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GCC4 status.
Charles Wilson wrote: Dave Korn wrote: it's going to be a fairly non-standard x-compiler in that it won't go into the usual $prefix/$target sysroot, it's going to look for headers and libs directly where they live under the native prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api, and it's going to use the native 'as' and 'ld'. So it's going to be an ugly hybrid beast Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just because we don't want two copies of w32api and mingw-runtime, or a cross-ld/cross-as? Yep, these were my original reasons. I think the maintenance headaches associated with an ugly hybrid beast outweigh those other, tiny, costs... Well, I'm as allergic as cgf seems to be to the idea of having duplicated-and-potentially-inconsistent sets of the same files around the place, but as the downthread consensus seems to be settling on, we can rearrange things to have a proper $prefix/$target dir and build a proper one. (More to come in follow-on responses.) cheers, DaveK
Re: GCC4 status.
Dave Korn wrote:
Well, I'm as allergic as cgf seems to be to the idea of having
duplicated-and-potentially-inconsistent sets of the same files around the
place,
D'oh. I was forgetting that the cross compiler would be a cygwin app.
For some reason I was thinking that it wouldn't be able to understand
symlinks, so it needed actual files (copies) for its relocated w32api
and mingw-runtime headers/libs. Then again, the native cygwin compiler
is obviously a cygwin app, so it's just a reasonable to put the real
files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate
/usr/[include|lib]/[w32api] with symlinks.
For mingw-runtime, the only reason not to completely relocate /ITS/
headers, libs, and objects (but not mingwm10.dll and docs) is backwards
compatibility with existing -mno-cygwin-capable compilers, or if Dave
doesn't want to respin gcc-3.4.4-999 to look in the new location. The
new cygwin-only gcc shouldn't care about mingw-runtime at all.
To close out the relocate vs. copy vs. symlink subthread: I was also
thinking of the two copies problem from the w32api-maintainer's
perspective. I don't consider the following:
$ configure --prefix=/usr/i686-pc-mingw32 \
--includedir=${prefix}/include/w32api \
--libdir=${prefix}/lib/w32api
$ make make install DESTDIR=/tmp/foo
...
$ configure --prefix=/usr \
--includedir=${prefix}/include/w32api \
--libdir=${prefix}/lib/w32api
$ make make install DESTDIR=/tmp/foo
...
$ make-pkg w32api /tmp/foo/
or
$ make-pkg w32api /tmp/foo/usr
$ make-pkg mingw-cross-w32api /tmp/foo/i686-pc-mingw32
to be very prone to inconsistency. Heck, the pkg-build script could
even include a giant diff -urN sanity check.
However, if end-users are in the habit of editing stuff in
/usr/include/w32api/ in-place, or (in the separate packages case) don't
upgrade both related packages together for whatever reason, then...yeah,
ok, things could get messed up.
but as the downthread consensus seems to be settling on, we can
rearrange things to have a proper $prefix/$target dir and build a proper one.
(More to come in follow-on responses.)
Hmm. Maybe the final gcc-3.4.4-999 should be gcc-3.4.4-990. Just in
case there are unanticipated wrinkles. g
--
Chuck
Re: GCC4 status.
Charles Wilson wrote: D'oh. I was forgetting that the cross compiler would be a cygwin app. For some reason I was thinking that it wouldn't be able to understand symlinks, so it needed actual files (copies) for its relocated w32api and mingw-runtime headers/libs. Then again, the native cygwin compiler is obviously a cygwin app, so it's just a reasonable to put the real files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate /usr/[include|lib]/[w32api] with symlinks. Of course, the cygwin1.dll itself is a MinGW app, so should live in /usr/i686-pc-mingw32/bin ! For mingw-runtime, the only reason not to completely relocate /ITS/ headers, libs, and objects (but not mingwm10.dll and docs) is backwards compatibility with existing -mno-cygwin-capable compilers Yep, so since it's just a symlink that's what we'll do. Hmm. Maybe the final gcc-3.4.4-999 should be gcc-3.4.4-990. Just in case there are unanticipated wrinkles. g Nah, I'll just append an extra '9' if I ever need to respin it, thus indicating that the final release ever would be gcc-3.4.4-aleph-null, which I will be approaching asymptotically! :-) cheers, DaveK
Re: GCC4 status.
On Tue, Feb 24, 2009 at 09:29:36AM -0500, Charles Wilson wrote:
Dave Korn wrote:
Well, I'm as allergic as cgf seems to be to the idea of having
duplicated-and-potentially-inconsistent sets of the same files around the
place,
D'oh. I was forgetting that the cross compiler would be a cygwin app.
For some reason I was thinking that it wouldn't be able to understand
symlinks, so it needed actual files (copies) for its relocated w32api
and mingw-runtime headers/libs. Then again, the native cygwin compiler
is obviously a cygwin app, so it's just a reasonable to put the real
files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate
/usr/[include|lib]/[w32api] with symlinks.
For mingw-runtime, the only reason not to completely relocate /ITS/
headers, libs, and objects (but not mingwm10.dll and docs) is backwards
compatibility with existing -mno-cygwin-capable compilers, or if Dave
doesn't want to respin gcc-3.4.4-999 to look in the new location. The
new cygwin-only gcc shouldn't care about mingw-runtime at all.
To close out the relocate vs. copy vs. symlink subthread: I was also
thinking of the two copies problem from the w32api-maintainer's
perspective. I don't consider the following:
$ configure --prefix=/usr/i686-pc-mingw32 \
--includedir=${prefix}/include/w32api \
--libdir=${prefix}/lib/w32api
$ make make install DESTDIR=/tmp/foo
...
$ configure --prefix=/usr \
--includedir=${prefix}/include/w32api \
--libdir=${prefix}/lib/w32api
$ make make install DESTDIR=/tmp/foo
...
$ make-pkg w32api /tmp/foo/
or
$ make-pkg w32api /tmp/foo/usr
$ make-pkg mingw-cross-w32api /tmp/foo/i686-pc-mingw32
to be very prone to inconsistency. Heck, the pkg-build script could
even include a giant diff -urN sanity check.
You're not thinking about this from the proper perspective if you think
that the package maintainer is the one who would have problems with two
copies.
cgf
Re: GCC4 status.
On Tue, Feb 24, 2009 at 10:14:51AM +0100, Corinna Vinschen wrote:
On Feb 24 00:27, Charles Wilson wrote:
Christopher Faylor wrote:
On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
Dave Korn wrote:
it's going to be a fairly non-standard
x-compiler in that it won't go into the usual $prefix/$target sysroot,
it's
going to look for headers and libs directly where they live under the
native
prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and
/lib/w32api,
and it's going to use the native 'as' and 'ld'. So it's going to be an
ugly
hybrid beast
Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
because we don't want two copies of w32api and mingw-runtime, or a
cross-ld/cross-as?
I think the maintenance headaches associated with an ugly hybrid beast
outweigh those other, tiny, costs...
I agree. I think we should relocate
relocate? But the regular cygwin gcc needs at least w32api, and that
location is hardcoded in its specs file. Which means that relocate
implies - respin gcc-3.4.4-999, and respin gcc-4.2.3. And it doesn't
really make sense for the cygwin-gcc specs to specify always look in
/usr/i686-pc-mingw32/include/[w32api]. Whuh, huh? *-mingw32?
It makes more sense to me that we have two different w32api packages:
the regular one that installs into /usr/[include|lib]/w32api, and a
mingw-cross-w32api that installs into
/usr/${mingw-triple}/[include|lib]/[w32api].
IMO it would be much easier to keep mingw and w32api in place and just
create matching symlinks in /usr/i686-pc-mingw32. This way you can
create a standard compiler *and* keep the include and lib files in
place. We can't move all of it out of the way anyway. We need at least
the mingw DLL in /bin since some Cygwin tools rely on it.
Maybe I'm missing something but I just checked every executable in my
bin area and I didn't find any that relied on a mingw DLL.
w32api headers and linking against Windows libs in Cygwin applications
might not be very POSIX compliant, but is necessary. Every Cygwin
application you link must be linked against kernel32.dll and friends.
That's why I talked about making selective symlinks into /usr/lib.
Maybe, to be kind, we could create a /usr/mingw directory so that people
could add -L/usr/mingw/lib to their link lines rather than
-L/usr/i686-pc-mingw/lib .
There's also still a lot of Windows functionality we can't cover in
Cygwin. USB access as in libusb-win32 comes to mind.
I don't see what a separate package has to do with anything. I'm just
talking about making sure that the mingw packages live where they should
rather than where they have been historically - and I'm actually to
blame for some of the poor choices for these directories.
I wouldn't normally suggest such a radical change but since we're talking
about releasing new versions of gcc this seems like a good time to clean
things up.
cgf
Re: GCC4 status.
On Feb 24 11:35, Christopher Faylor wrote: On Tue, Feb 24, 2009 at 10:14:51AM +0100, Corinna Vinschen wrote: IMO it would be much easier to keep mingw and w32api in place and just create matching symlinks in /usr/i686-pc-mingw32. This way you can create a standard compiler *and* keep the include and lib files in place. We can't move all of it out of the way anyway. We need at least the mingw DLL in /bin since some Cygwin tools rely on it. Maybe I'm missing something but I just checked every executable in my bin area and I didn't find any that relied on a mingw DLL. My fault. I blindly assumed that cygcheck and strace link against the mingw dll but they really just need msvcrt.dll. w32api headers and linking against Windows libs in Cygwin applications might not be very POSIX compliant, but is necessary. Every Cygwin application you link must be linked against kernel32.dll and friends. That's why I talked about making selective symlinks into /usr/lib. and /usr/include, please. Maybe, to be kind, we could create a /usr/mingw directory so that people could add -L/usr/mingw/lib to their link lines rather than -L/usr/i686-pc-mingw/lib . I don't think that's necessary. I just dread a situation where you suddenly don't have w32api in the default include and lib search paths. I don't have problems with mingw. Just w32api is essential IMO. If I missed this in the discussion up to this point, feel free to ignore me. Otherwise, just make sure that w32api is searched by default. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GCC4 status.
Corinna Vinschen wrote: I don't think that's necessary. I just dread a situation where you suddenly don't have w32api in the default include and lib search paths. I don't have problems with mingw. Just w32api is essential IMO. If I missed this in the discussion up to this point, feel free to ignore me. Otherwise, just make sure that w32api is searched by default. Back-compat is a given, don't worry! cheers, DaveK
Re: update - Vista: no copy/paste X - MS
Dick Repasky-2 wrote: not being able to copy from an X application (xterm or nedit) and paste into Windows Notepad. For what it's worth, and notwithstanding the need for deeper analysis and a fix, I can report that, disabling the Office clipboard (e.g. from Outlook), copypaste work for me from emacs run on X to the Windows Notepad, on Vista. Marc Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6000 ... Cygwin DLL version info: DLL version: 1.5.25 DLL epoch: 19 -- View this message in context: http://www.nabble.com/update---Vista%3A-no-copy-paste-X--%3E-MS-tp22164522p22181085.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Xwin_GL source (was Re: X.org 7.4 dying under Geomview)
Phil Betts wrote: If acceleration matters so much to you, I'm sure Yaakov and Jon would welcome patches to enable it ;-) The source for the experimental version isn't available via setup.exe, and I haven't been able to locate the source elsewhere. Since the original package is still available (even if obsolete), I thought that the GPL insisted that the source was similarly available. I would like to take a diff of the two X11R6 server packages, with a view to merging the changes into the current, much changed, source, but without access to the source for both accelerated and unaccelerated, this is impossible. Does anyone know where one might find the source package for xorg-x11-xwin-gl-6.8.99.901-1? I've tried the Cygwin Time Machine, but it appears to be down. As far as I know, there is no separate source package for xwin-gl, it is simply the same X server built with different flags. This mail [1], linked to from the todo web page, seems to explain how to build with the acceleration code enabled, in the old, Imakefile'd monolithic tree. I haven't looked at all as to if it's a simple of just finding the correct thing to turn on in the modular tree, or how much this has rusted due to other internal changes in the X server or GLX over the intervening years. http://cygwin.com/ml/cygwin-xfree/2004-03/msg1.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: -query not working on cygwin/windows
km4hr wrote: Phil Betts-2 wrote: km4hr wrote: Perhaps you missed my suggestions here: http://cygwin.com/ml/cygwin-xfree/2009-02/msg00222.html Try the telnet check first to see if the port is accessible from Windows because that only takes a few seconds. (Make sure you run the cygwin telnet.exe) Phil, Thanks for hanging in there. I tried your telnet suggestion. I get the following: $telnet xxx.xxx.xxx.xxx 6000 trying xxx.xxx.xxx.xxx... Connected to xxx.xxx.xxx.xxx. Escape character is '^]'. The above is all I get. A login prompt never appears. I waited for several minutes. When I press Ctrl-c I get: Connection closed by foreign host. If I telnet using an unopen port I the response gets past the trying statement. Your quoting went a bit wrong there. Sorry, I should have explained that that was the expected outcome. If you get the Connected to message, the port is open and you can close the connection. The proper way to terminated a telnet session from that situation is to press Ctrl-] (the Escape character mentioned in the message). You then get a telnet prompt, where you just type quit. You wouldn't normally expect a prompt (unless the port was 23 - telnet's own). In theory, if you knew enough about the protocol expected on the opened port, you could simulate a normal connection and debug the connection using telnet, but you have to have a certain masochistic streak to try it! So, now we know that the port is accessible from Windows. In that case, it *should* work, so something else is interfering. Have you investigated the BLODA angle? Prime suspects are anti-virus and other security software, but hardware drivers have caused problems too. These programs inject themselves into every running process at a fairly low level and, whilst they are mostly benign, can cause nasty, spurious problems, particularly when the code you are trying to run is slightly off the beaten track. X and XCMCP probably falls into that category for Windows machines. The usual advice is to uninstall these, rather than just disable them. The faulty components are frequently left in place when disabled. Once you have ruled out a candidate, you can reinstall it. If you do find one that is causing the problem, it may be possible to configure it in a way which avoids the problem (e.g. disabling real-time virus scanning). You can often spot BLODA by running the program which is failing, and then seeing which DLLs are loaded using something like Process Explorer. Any unexpected DLLs, particularly if not under C:\Windows or C:\cygwin are prime suspects. In your case, because the -query option is failing, you won't get chance to see the DLLs before X terminates, so you could just start a normal server (e.g. via startxwin.bat) instead. You may find that an app that is not on the BLODA is causing the problem. If so, a message to the main cygwin list would be appreciated so that the BLODA can be updated. If the BLODA hunt fails, you could try running the server via strace so that the point of failure might be spotted, but I'm not familiar with the source. Yaakov or Jon would probably be better at making sense of that. Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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: xdvi unexplained locale problem
Dan Tsafrir wrote: On Wed, Feb 18, 2009 at 3:02 PM, Mike Ayers mike_ay...@tvworks.com wrote: Dan Tsafrir wrote: open xdvi, I get the following error message: Warning: locale not supported by C library, locale unchanged Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default Warning: Unable to load any usable fontset Try unsetting LOCPATH: This didn't work either. In fact, I tried unset-ing this and very many other env variables before posting the question here. I'm sorry, I must have left my telepathy switched off. Anything else that you've tried that you'd like to mention now :-) Looking at your cygcheck output some more, I notice you seem to have a lot of old X DLLs in /usr/X11R6/bin/ (which should have been removed by setup, but haven't been for some reason [in use when setup was run?]). Since xdvi is still in /usr/X11R6/bin, this might well be causing a problem (the Windows loader looks in the directory from which the application loaded to find DLLs first, I think?) It seems to me that the behavior is unrelated to any env variables. It appears as though, for some unexplained reason, somewhere along the way, xdvi or X think they need to change to a locale other than C. Googling the error messages shows that ubuntu users faced a similar problem in early 2007 (related to xdvi and xfig): https://bugs.launchpad.net/ubuntu/+source/control-center/+bug/2066 I don't actually see the locale not supported warning anywhere in that bug report, so I am unsure of it's relevance. Some thought it was an xorg problem. The suggested workarounds (e.g., setting a LANG=C env var) don't work for me. Am I the only one that gets this error message for xdvi on cygwin? I'm sorry to say that, yes, you are abnormal :-) xdvi runs without this error message for me. -- 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: Reproducing the cygwin X problems
Dan Tsafrir wrote: On Fri, Feb 20, 2009 at 1:05 PM, Mike Ayers wrote: I can neither confirm nor deny this, as I don't have ClipBook available. Did you try to run 'clipbrd' through start-run ? I just kill Xwin.exe forcibly in task manager - it takes all X apps with it. Right. However, the better trick I discovered recently is to click on VNC's taskbar icon and close it. Once it closes, the X applications recover and can cut-n-pste with Windows apps. Also, because VNC is VNC, no setup is lost there either - I can reconnect and my console is unharmed. This too works for me (but as you say, only if I kill the vncviewer through the context menu that pops up when right clicking its taskbar icon; strangely, killing it through the top right x doesn't produce a similar effect). Thanks! I suspect the problem here may be contention between the two applications that want to share the clipboard. Our other report implicated Office clipboard, which may be doing the same thing..? Dan Mike, Thanks very much for this information on the clipboard problems. I've been able to reproduce something similar to the problems you describe, so I will spend some time trying to fix it. It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? -- 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: Reproducing the cygwin X problems
From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: Tuesday, February 24, 2009 11:14 AM Thanks very much for this information on the clipboard problems. I've been able to reproduce something similar to the problems you describe, so I will spend some time trying to fix it. Sweet! It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? Multi-core, I believe, although I can't tell for sure if I'm not just hyperthreading without rebooting (not an option at the moment). HTH, Mike -- 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: Reproducing the cygwin X problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Dan Tsafrir Sent: Friday, February 20, 2009 6:30 PM Pardon my ignorance, but until now I wasn't aware there is such a thing as office clipboard. However, according to this http://en.wikipedia.org/wiki/Clipboard_manager even if I have it installed, the office clipboard is open as long as one of the office suite applications are open, and my cygwin copy-paste problems occur even if the only applications alive are (1) a cygwin xterm and (2) a vncviewer. So it appears my problem is unrelated to the office clipboard. Wikipedia?! Try the source. This was the only way I found to ensure that OC is not running: http://support.microsoft.com/kb/207438 I have Office 2003, and OC was disabled by default (because I have the value edition?) HTH, Mike -- 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: Cygwin-X on Windows 7 Beta Success!
Fredrik, Thanks! I got it working with a reinstall and a rebaseall with double the default offset. GNUemacs does not survive rebaseall. Paul Fredrik Staxeng wrote: Paul Loewenstein paul.loewenst...@gmail.com writes: Fredrik, On 64-bit Windows 7, I cannot get Cygwin/X windows to accept keyboard input. Are you using 32-bit or 64-bit? 64. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server causing IE lockups
On Tue, 10 Feb 2009 13:05:36 -0500 Frédéric Bron wrote: Maybe we have an exploit on our systems. Or possibly we have the same video driver? Or same network card. Etc. I'll gather together what hardware I've got and we can compare. I have a notebook : DELL Latitude D830, Video = nVidia Quadro NVS 140M I have an ATI Mobility FireGL V5k. But I have put this on the back-back burner for now. My work-around is to only use X for when I need gnuplot and then I exit from X. -- 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: Cygwin-X on Windows 7 Beta Success!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul Loewenstein wrote: GNUemacs does not survive rebaseall. Known issue; reinstall the libncurses7 (and libtiff4?) DLLs. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmku9sACgkQpiWmPGlmQSO4CACfXtoPzOo9p3zBXfpOuZ+Z+hWB JNwAn3AYjRvwZ7uwe7Nn/sLUniUreQvj =G4Xl -END PGP SIGNATURE- -- 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: Reproducing the cygwin X problems
On Tue, Feb 24, 2009 at 2:13 PM, Jon TURNEY It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? Indeed, I'm using a dual core machine. However, in an attempt to test your hypothesis, I've set the affinity of XWin.exe, emacs, and the vncviewer to only use CPU0 (through the task manager). This had no positive affect on the problem: the instant I highlighted some text within emacs my copy-paste functionality was dead, regardless of affinity. --Dan -- 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: Reproducing the cygwin X problems; MinTTY, too
Dan Tsafrir wrote: On Tue, Feb 24, 2009 at 2:13 PM, Jon TURNEY It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? Indeed, I'm using a dual core machine. However, in an attempt to test your hypothesis, I've set the affinity of XWin.exe, emacs, and the vncviewer to only use CPU0 (through the task manager). This had no positive affect on the problem: the instant I highlighted some text within emacs my copy-paste functionality was dead, regardless of affinity. --Dan -- 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/ FWIW, I'm having a similar proble with MinTTY. If I select text in a MinTTY window, then copy text withing a GUI app, like TextPad (http://textpad.com), clipboard stops working for all apps. If I ten return to the original, MinTTY window, and reselect text, paste it, that works and then copy and paste work in all apps, again. Lee -- 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: BLODA list
Greg Chicares wrote: On 2009-02-21 12:23Z, Vincent R. wrote: Is there any BLODA list ? Yes, it's in the FAQ: It's also built into cygcheck -s. Look for app conflicts. -- 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: wget, ssh, ssh-agent hang in socket_cleanup
On Feb 22 18:24, Paul McFerrin wrote: I've been having the same problem for the past two weeks. Just didn't know where to look. Thanks for sharing. Maybe we can get someone on this. Wget would just HANG intermittently in the Connecting phase. I don't observe this problem. Does updating to Cygwin 1.7 help? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] makeinfo: too many open files
On Feb 20 22:18, Charles Wilson wrote: I ran into the following problem building libtool under cygwin-1.7 (makeinfo from texinfo-4.8a-1): makeinfo -I doc -I /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc -o /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.info /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi:5485: @include `PLATFORMS': Too many open files. /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi:6191: @include `fdl.texi': Too many open files. makeinfo: Removing output file `/usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.info' due to errors; use --force to preserve. When using the same version of makeinfo under cygwin-1.5, there are no problems. I see that Eric asked about (the same?) problem over on bug-texinfo, but I don't see any resolution. It looks like a cygwin-1.7 problem, not a texinfo problem, to me... http://lists.gnu.org/archive/html/bug-texinfo/2009-01/msg00013.html Eric, did anything ever come of this? Any debugging efforts, maybe? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] rebaseall doesn't solve the problem
On Feb 20 21:27, Charles Wilson wrote: Using process explorer, I find that for SOME reason, even in the parent perl, the Cwd.dll (one of the DLLs shipped with perl, in /usr/lib/perl5/5.10/i686-pc-cygwin/auto/Cwd/Cwd.dll) is being loaded in a strange location: Image Base: 0x5d6a Location in Parent: 0x0086 Location in Child : 0x014E I can't see that there is any conflict at the image base location of 0x5d6a, so I'm not sure why, in the parent, Cwd.dll was loaded that low. However, the low memory region is rife with conflict, and in fact, in the child: C:\Windows\system32\locale.nls image base: 0x0 mapped location: 0x0096 mapped size: 0x0037F000 which means that locale.nls extends all the way down to 0x005E1000, so Cwd.dll can't go at 0x0086. Hm? Isn't that end_of_mapped_region = mapped_location + mapped_size? Rebasing won't solve this problem, because Cwd.dll is NOT being loaded at the rebased (0x5d6a) location even tho, as far as I can tell, there is no conflict there. Instead, it's being loaded at a traffic heavy location for no good reason that I can see -- and I keep getting hit by passing cars. Help? I'm wondering if that's a result of ASLR in Vista. The document http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf describes, starting at page 11, a registry key to influence Vista's ASLR behaviour. Does that change the behaviour for you? If so, there's nothing Cygwin can do against that. In the long run, only a native fork() implementation would help. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] makeinfo: too many open files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 2/24/2009 2:20 AM: On Feb 20 22:18, Charles Wilson wrote: I ran into the following problem building libtool under cygwin-1.7 (makeinfo from texinfo-4.8a-1): /usr/src/packages/libtool/22/libtool-2.2.7a-10/src/libtool/doc/libtool.texi:6191: @include `fdl.texi': Too many open files. When using the same version of makeinfo under cygwin-1.5, there are no problems. I see that Eric asked about (the same?) problem over on bug-texinfo, but I don't see any resolution. It looks like a cygwin-1.7 problem, not a texinfo problem, to me... http://lists.gnu.org/archive/html/bug-texinfo/2009-01/msg00013.html Eric, did anything ever come of this? Upstream could not reproduce it on Linux, and I haven't revisited the issue since. The upstream analysis was that there was no fd leak, but that says nothing about how many files are open at once. Any debugging efforts, maybe? I guess an strace would be worthwhile, but haven't run one yet. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmj7OAACgkQ84KuGfSFAYCIdQCgtAaAW8rAE/YeRwIeM3QXlfuu 9YcAniiKep77geG9P0ZFrcglH5mP2zXF =zJVB -END PGP SIGNATURE- -- 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/
Git broken with cygwin-1.7
Hi, Everytime I try to checkout source code with git on cygwin-1.7 it fails while the same command works fine on cygwin-1.5/ For instance : git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git Initialized empty Git repository in /home/Vincent/projects/sparse/.git/ remote: Counting objects: 7642, done. remote: Compressing objects: 100% (2414/2414), done. fatal: read error on input: Bad address99 KiB | 103 KiB/s fatal: index-pack failed CYGWIN_NT-5.1 gynoid 1.7.0(0.200/5/3) 2009-02-20 17:20 i686 Cygwin git version 1.6.1.2 -- 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: Git broken with cygwin-1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Vincent R. on 2/24/2009 6:07 AM: git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git Initialized empty Git repository in /home/Vincent/projects/sparse/.git/ remote: Counting objects: 7642, done. remote: Compressing objects: 100% (2414/2414), done. fatal: read error on input: Bad address99 KiB | 103 KiB/s fatal: index-pack failed You can work around this by cloning via http protocol instead of git. I have seen occasional read errors as well, but have had a hard time reliably reproducing them. I guess it's a good thing to report that your sample failed in the same place for me. The fact that the error is EFAULT makes it hard to tell whether git is making an incorrect call, or whether it really is tickling a cygwin regression (perhaps in mmap or pread). Perhaps an strace will help isolate this. I'll see if I can come up with a simpler test case. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net volunteer cygwin git maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmj+IsACgkQ84KuGfSFAYB6CwCdGvPzyZmg/KnbKFNIBLFMcjEH nP0An1hE/Xam51RGp54D19oRw9OnkTRL =uvCH -END PGP SIGNATURE- -- 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: Git broken with cygwin-1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 2/24/2009 6:39 AM: You can work around this by cloning via http protocol instead of git. I have seen occasional read errors as well, but have had a hard time reliably reproducing them. I guess it's a good thing to report that your sample failed in the same place for me. Phooey - it passes under strace. I hate finding heisenbugs. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmj+TgACgkQ84KuGfSFAYDxvgCg0qugRifF71GUCgcmxcWKKV1v 5soAn2Zxzzw4SUDo7KSwCW882kK0et4A =wxwV -END PGP SIGNATURE- -- 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: {ncurses/libncurses-devel/libncurses8/ncurses-demo}-5.7-1
rhubbell wrote: Just curious since I'm new here. Why do announcements go to this list? Isn't there an announcement list? The announce list is mirrored to the main list because the information is vital. Things like changing CRLF line-end handling in bash create enough upheaval even when they /are/ heavily-trailed here! Yes, I can filter these to trash easily enough. Obviously, since if you were at all bothered, you wouldn't have just reposted yourself and every single one of the rest of us a whole duplicate copy of the entire message. Thanks a bunch! Please believe me, the value of your wit and wisdom to the rest of us is not /so/ vast that we have to be notified of your every thought the moment it occurs to you just as fast as you can commit it to paper, without a moment to waste. Take the extra ten seconds to trim the spam off your replies; we'll still be here. cheers, DaveK -- 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/
stat() returning EFAULT?
Hey all,
I noticed this weird cygwinism and wrote a little test case. It seems
stat() is returning EFAULT on some of my files. I've done some digging
through Cygwin source but couldn't see the source of the problem.
The testcase is a simple test.c which is compiled to test.exe. After
that, it does a stat(test) and a stat(test.exe). It doesn't matter
if it runs stat on itself or on a different binary, so I chose to keep
things simple.
Here's the test case and output:
#include errno.h
int main() {
if(stat(test) != 0) perror(Calling stat() on test);
if(stat(test.exe) != 0) perror(Calling stat() on test.exe);
return 0;
}
// Calling stat() on test: Bad address
// Calling stat() on test.exe: Bad address
As far as I could see, the strace wasn't very informative. I've attached
the relevant parts.
This is Cygwin from the current bleeding-edge CVS. Could anybody explain
why stat() is returning -1 with errno set to EFAULT?
Sjors
// stat(test)
27 36374 [main] test 2236 dll_crt0_1: user_data-main 0x401050
23 36397 [main] test 2236 __set_errno: void dll_crt0_1(void*):908 val 0
62 36459 [main] test 2236 stat64: entering
26 36485 [main] test 2236 normalize_posix_path: src test
24 36509 [main] test 2236 cwdstuff::get: posix /home/Sjors/tests/statefault
22 36531 [main] test 2236 cwdstuff::get: (/home/Sjors/tests/statefault) =
cwdstuff::get (0xC90008, 32768, 1, 0), errno 0
24 36555 [main] test 2236 normalize_posix_path:
/home/Sjors/tests/statefault/test = normalize_posix_path (test)
22 36577 [main] test 2236 mount_info::conv_to_win32_path:
conv_to_win32_path (/home/Sjors/tests/statefault/test)
24 36601 [main] test 2236 set_flags: flags: binary (0x2)
22 36623 [main] test 2236 mount_info::conv_to_win32_path: src_path
/home/Sjors/tests/statefault/test, dst
E:\overig\cygwin\root\home\Sjors\tests\statefault\test, flags 0xA, rc 0
43 3 [main] test 2236 symlink_info::check: 0xC034 =
NtQueryInformationFile
(\??\E:\overig\cygwin\root\home\Sjors\tests\statefault\test)
46 36712 [main] test 2236 symlink_info::check: not a symlink
33 36745 [main] test 2236 symlink_info::check: 0 = symlink.check
(E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe, 0x223BA0) (0xA)
25 36770 [main] test 2236 path_conv::check:
this-path(E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe),
has_acls(1)
41 36811 [main] test 2236 build_fh_pc: fh 0x6123C564
26 36837 [main] test 2236 stat_worker:
(\??\E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe, 0x57,
0x6123C564), file_attributes 544
--- Process 2236, exception C005 at 611046AC
80 36917 [main] test 2236 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x611046AC sp 0x224AD4
25 36942 [main] test 2236 _cygtls::handle_exceptions: In
cygwin_except_handler sig 11 at 0x611046AC
28 36970 [main] test 2236 _cygtls::handle_exceptions: In
cygwin_except_handler calling 0x0
23 36993 [main] test 2236 __set_errno: void
_cygtls::return_from_fault():259 val 14
23 37016 [main] test 2236 stat_worker: -1 =
(\??\E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe, 0x57)
// perror(Calling stat() on test)
75 37091 [main] test 2236 fhandler_base::write: binary write
calling stat() on test 101 37192 [main] test 2236 fhandler_base::write:
binary write
:95 37287 [main] test 2236 fhandler_base::write: binary write
Bad address 134 37421 [main] test 2236 fhandler_base::write: binary write
// stat(test.exe)
94 37515 [main] test 2236 stat64: entering
23 37538 [main] test 2236 normalize_posix_path: src test.exe
22 37560 [main] test 2236 cwdstuff::get: posix /home/Sjors/tests/statefault
22 37582 [main] test 2236 cwdstuff::get: (/home/Sjors/tests/statefault) =
cwdstuff::get (0xC90008, 32768, 1, 0), errno 14
24 37606 [main] test 2236 normalize_posix_path:
/home/Sjors/tests/statefault/test.exe = normalize_posix_path (test.exe)
23 37629 [main] test 2236 mount_info::conv_to_win32_path:
conv_to_win32_path (/home/Sjors/tests/statefault/test.exe)
22 37651 [main] test 2236 set_flags: flags: binary (0x2)
23 37674 [main] test 2236 mount_info::conv_to_win32_path: src_path
/home/Sjors/tests/statefault/test.exe, dst
E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe, flags 0xA, rc 0
45 37719 [main] test 2236 symlink_info::check: not a symlink
32 37751 [main] test 2236 symlink_info::check: 0 = symlink.check
(E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe, 0x223BA0) (0xA)
25 37776 [main] test 2236 path_conv::check:
this-path(E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe),
has_acls(1)
40 37816 [main] test 2236 build_fh_pc: fh 0x6124C674
24 37840 [main] test 2236 stat_worker:
(\??\E:\overig\cygwin\root\home\Sjors\tests\statefault\test.exe, 0x57,
0x6124C674), file_attributes 544
--- Process 2236, exception
Re: stat() returning EFAULT?
Sjors Gielen, le Tue 24 Feb 2009 16:54:28 +0100, a écrit :
Here's the test case and output:
#include errno.h
int main() {
if(stat(test) != 0) perror(Calling stat() on test);
if(stat(test.exe) != 0) perror(Calling stat() on test.exe);
return 0;
}
Compile with -Wall, you're missing the second argument of stat().
Samuel
--
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: Git broken with cygwin-1.7
On Tue, Feb 24, 2009 at 06:42:17AM -0700, Eric Blake wrote: According to Eric Blake on 2/24/2009 6:39 AM: You can work around this by cloning via http protocol instead of git. I have seen occasional read errors as well, but have had a hard time reliably reproducing them. I guess it's a good thing to report that your sample failed in the same place for me. Phooey - it passes under strace. I hate finding heisenbugs. Have you tried: strace -b100 ... I added that buffering capability because it sometimes help find this type of problem. 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: gcc compile problem: error: stray \168 in program
Hi Dave and Tim
1. Output from od -tx1 test.c
-BEGIN---
000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e
020 68 3e 0a 0a 69 6e 74 20 6d 61 69 6e 28 29 0a 20
040 7b 0a 70 72 69 6e 74 66 28 a8 54 65 73 74 20 74
060 68 69 73 a8 29 3b 0a 72 65 74 75 72 6e 28 30 29
100 3b 0a 20 7d 0a
105
-END---
2. Output from od- tx1 -a test.c
-BEGIN---
000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e
# i n c l u d e sp s t d i o .
020 68 3e 0a 0a 69 6e 74 20 6d 61 69 6e 28 29 0a 20
h nl nl i n t sp m a i n ( ) nl sp
040 7b 0a 70 72 69 6e 74 66 28 a8 54 65 73 74 20 74
{ nl p r i n t f ( ( T e s t sp t
060 68 69 73 a8 29 3b 0a 72 65 74 75 72 6e 28 30 29
h i s ( ) ; nl r e t u r n ( 0 )
100 3b 0a 20 7d 0a
; nl sp } nl
105
-END---
Tim McDaniel-2 wrote:
On Mon, 23 Feb 2009, Dave Korn dave.korn.cyg...@googlemail.com wrote:
Nor do I, but let's see what's in that file: can you show us the
output you get from running od -tx1 test.c on your testcase
please, and tell us exactly what editor you used.
I personally prefer od -tx1 -a test.c: it should add ASCII versions
of each character, to make it faster to find particular positions.
Also, type od -tx1 at a command line without any filename
following it, type a quote mark, then press enter, then Ctrl+D, and
show us what that says.
Being ultra-precise: type
od -tx1
at a command line, and then press enter. That will start the octal
dump program. The quote mark (meaning ) and enter is the one line
of input.
--
Tim McDaniel, t...@panix.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/
--
View this message in context:
http://www.nabble.com/gcc-compile-problem%3A-error%3A-stray-%5C168-in-program-tp22145156p22185314.html
Sent from the Cygwin list mailing list archive at Nabble.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: gcc compile problem: error: stray \168 in program
Ok here are more clues and I think this should help you: 1. From the command prompt from windows, I tried this - od -tx1 ENTER - ENTER (Note: I have to type double quotes twice always and I get two double quotes. I use backspace to remove one every time. A single double quotes produces no output on the screen ) -CTRL-D -BEGIN 000 22 0a 002 -END 2.From xterm Now I cannot get to type the double quotes at all. Also within vi in xterm. From windows command prompt, the double quotes gets printed as explained in 1 above (have to type it twice to get 2 s , use backspace to delete one to finally get 1 , as explained above. ) I closed everything and launched xterm again and still I cant get to type the in xterm or vi within xterm. Hope these inputs help you CHeers CM Tim McDaniel-2 wrote: On Mon, 23 Feb 2009, Dave Korn dave.korn.cyg...@googlemail.com wrote: Nor do I, but let's see what's in that file: can you show us the output you get from running od -tx1 test.c on your testcase please, and tell us exactly what editor you used. I personally prefer od -tx1 -a test.c: it should add ASCII versions of each character, to make it faster to find particular positions. Also, type od -tx1 at a command line without any filename following it, type a quote mark, then press enter, then Ctrl+D, and show us what that says. Being ultra-precise: type od -tx1 at a command line, and then press enter. That will start the octal dump program. The quote mark (meaning ) and enter is the one line of input. -- Tim McDaniel, t...@panix.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/ -- View this message in context: http://www.nabble.com/gcc-compile-problem%3A-error%3A-stray-%5C168-in-program-tp22145156p22186369.html Sent from the Cygwin list mailing list archive at Nabble.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: gcc compile problem: error: stray \168 in program
On Tue, 24 Feb 2009, grip chandramohan.usec...@gmail.com wrote:
2. Output from od- tx1 -a test.c
-BEGIN---
000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e
# i n c l u d e sps t d i o .
020 68 3e 0a 0a 69 6e 74 20 6d 61 69 6e 28 29 0a 20
h nl nl i n t sp m a i n ( ) nl sp
040 7b 0a 70 72 69 6e 74 66 28 a8 54 65 73 74 20 74
{ nl p r i n t f ( ( T e s t sp t
060 68 69 73 a8 29 3b 0a 72 65 74 75 72 6e 28 30 29
h i s ( ) ; nl r e t u r n ( 0 )
100 3b 0a 20 7d 0a
; nl sp } nl
105
-END---
THank you for providing that. I've deleted spaces so that the text
representations line up under the hex representations (why od doesn't
do that I don't know; nor do I know how to make od do that).
They really ARE umlauts in Latin-1, hex a8 shown above. Why any other
program displays them as double quotes is beyond me: od apparently
strips the high bit to display them (0xa8 becomes 0x28, which is ();
DOS codepage 437 would show an inverted question mark.
Anyway, go into your editor, delete the quotation marks that are
around the string, and retype them with the key that's probably next
to Enter on your keyboard. Then re-do od as above to make sure that
they show up as , hex code 22, instead of a8 or anything else.
--
Tim McDaniel, t...@panix.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: gcc compile problem: error: stray \168 in program
Tim McDaniel tmcd at panix.com writes: On Tue, 24 Feb 2009, grip Chandramohan.USecure at gmail.com wrote: 2. Output from od- tx1 -a test.c -BEGIN--- 000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e # i n c l u d e sps t d i o . THank you for providing that. I've deleted spaces so that the text representations line up under the hex representations (why od doesn't do that I don't know; nor do I know how to make od do that). Making od align output is easy - upgrade to cygwin 1.7 and coreutils 7.0, where you will then get my upstream patch that does just that ;) (and no, I won't port coreutils 7.0 to cygwin 1.5; I'm already swamped trying to get coreutils 7.1 and bash 4.0 built). They really ARE umlauts in Latin-1, hex a8 shown above. Why any other program displays them as double quotes is beyond me: od apparently strips the high bit to display them (0xa8 becomes 0x28, which is (); DOS codepage 437 would show an inverted question mark. That's because you used -a, instead of -c. od --help confirms that -a intentionally drops the high bit, producing ambiguous output: -a same as -t a, select named characters, ignoring high-order bit -b same as -t o1, select octal bytes -c same as -t c, select ASCII characters or backslash escapes ... a named character, ignoring high-order bit c ASCII character or backslash escape -- Eric Blake volunteer cygwin coreutils maintainer -- 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: gcc compile problem: error: stray \168 in program
grip Chandramohan.USecure at gmail.com writes: 1. From the command prompt from windows, I tried this - od -tx1 ENTER - ENTER (Note: I have to type double quotes twice always and I get two double quotes. I use backspace to remove one every time. A single double quotes produces no output on the screen ) That seems fishy. You are probably better off getting to the root of why isn't working the first time around. Perhaps a faulty .inputrc setting is at play? Or maybe a strange stty setting? -- Eric Blake -- 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: gcc compile problem: error: stray \168 in program
On Tue, 24 Feb 2009, Eric Blake e...@byu.net wrote: grip Chandramohan.USecure at gmail.com writes: 1. From the command prompt from windows, I tried this - od -tx1 ENTER - ENTER (Note: I have to type double quotes twice always and I get two double quotes. I use backspace to remove one every time. A single double quotes produces no output on the screen) That seems fishy. You are probably better off getting to the root of why isn't working the first time around. Perhaps a faulty .inputrc setting is at play? Or maybe a strange stty setting? Escape character in your terminal program, even? Though that seems unlikely to me: the terminal programs I've used of late look for ~ as the first character on a line only, and the double quotes are not at the start of a line. -- Tim McDaniel, t...@panix.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: gcc compile problem: error: stray \168 in program
On Tue, 24 Feb 2009, Tim McDaniel t...@panix.com wrote: On Tue, 24 Feb 2009, grip ....@x.xxx wrote: and so forth. I just realized I've been forgetting this list's custom of ripping out e-mail addresses, so I've sent out a bunch of unobfuscated ones lately. My apologies. -- Tim McDaniel, t...@panix.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/
[ANNOUNCEMENT] Updated: astyle-1.23-1
I've uploaded a new version astyle, 1.23-1, in keeping with the current upstream release. Note: This release is for Cygwin 1.7.x only, there is no release for Cygwin 1.5.x at this point. For a list of changes check out http://astyle.sourceforge.net/astyle_release_notes.html. 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 answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Chris -- Chris Sutcliffe http://emergedesktop.org -- 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/
file name too long
Hello, I updated my cygwin installation to 1.5.25-15 but I'm still getting 'file name too long' errors when trying to extract a .tgz archive that contains some really long pathnames. Here is an example of one of the errors: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. Interestingly, even some of the files that 'tar' can extract, 'ls' returns an error when I try to see the contents of the directory: ls: cannot access S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file0.fa: File name too long I found this (http://www.cygwin.com/ml/cygwin-developers/2008-01/msg0.html) discussion of what seems to be the same problem that I am having. So, was a fix ever implemented? Is there a workaround to this problem other than installing Linux? Thank you for your help, Paul -- Paul Cantalupo Research Specialist/Systems Programmer 559 Crawford Hall Department of Biological Sciences University of Pittsburgh Pittsburgh, PA 15260 Work: 412-624-4687 Fax: 412-624-4759 -- 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: [CFT] libtool on nix-cygwin cross, with wine
What's the [CFT] stand for? Call For Test? Are you requesting test volunteers? On Tue, 24 Feb 2009 00:01:19 -0500 Charles Wilson wrote: The most recent release of libtool (2.2.7a-1 for cygwin-1.5, and 2.2.7a-10 for cygwin-1.7) ought to support cross builds at least as well as libtool-1.5 did. Note that in *ordinary* cross builds (SomeBUILD - SomeHOST) you can't run the $host executables on the $build machine -- but you can still *build* them. That kind of thing has (hopefully) always worked, and still works, for -cygwin crosses. However, under certain conditions, it USED to be possible to run the $host (cygwin) executables on the $build machine, provided $build's CPU was x86, and $build had wine installed, and $build was running linux with the 'binfmt' kernel extension, and there was a cygwin installation in the wine arena, etc, etc. /That/ has been broken for about a year, due to a change in how wrapper executables are handled by libtool in libtool-2.2.2 and above. 1 == See, in the ANCIENT days, there was a wrapper script. When you built an executable for $host=cygwin, libtool would create myprog (a wrapper script) .libs/myprog.exe (the actual exe) The wrapper script would set $PATH and various other environment variables so that the EXE would be able to find its (as yet uninstalled) DLLs, and then it would launch the EXE. Obviously, scripts are not bound to any specific platform, so $build has no problem running the script. So as long as $build could execute EXE (via wine, etc), the the wrapper/EXE combo worked fine. Why'd we change it? Well, there IS one little problem with that scheme: the Makefile rule for building the EXE looks like this: ./my_prog$EXEEXT: my_prog.o stuff ... some libtool commands ... But libtool doesn't create ./my_prog$EXEEXT -- it creates a wrapper named ./my_prog with NO $EXEEXT. So make always believes that the executable must be rebuilt. 'make' - go link the exe. 'make check' - 'go link the exe again'. 'make install' - go link the exe. Very annoying. 2 == So, in the OLD days, we had a wrapper executable AND a wrapper script: my_prog.exe (not the real exe; just a wrapper exe) my_prog (the wrapper script) .libs/my_prog.exe (the real exe) The way this scheme worked was: (a) the wrapper exe would launch the wrapper script, (b) the wrapper script would set $PATH and such, and then (c) launch the real exe. This worked pretty well -- and was fairly transparent to cross builders: they'd try to run 'my_prog' (not my_prog.exe, because who types blahblah.EXE on unix?). But, my_prog is a shell script, and it Just Works(tm) like it did in the ANCIENT days. So cross-builders were happy -- they just ignored that wrapper exe (and, incidentally, never tested it...) So, what was wrong with this? Did we fix something that wasn't broken? Well, not exactly. About three years ago, cygwin added a new feature: you could set the 'transparent_exe' option in the CYGWIN variable. Then, you could pretend you were even more unixy: files which end in .exe to be used by appropriate functions when an input filename is specified with no extension. That is, you say spawn(foo) and if foo.exe exists, then cygwin will turn that in to spawn(foo.exe). So...what if I have foo.exe AND foo, and a really really want to spawn(foo) -- NOT spawn(foo.exe). Say, for instance: my_foo.exe my_foo Uh...don't do that. See, transparent_exe caused all KINDS of pain for libtool -- cygwin (and libtool) got really confused by the situation. However, as long as transparent_exe was just an option, we were ok though: you just had to follow some rules: 1) if transparent_exe, then do not put files that differ only in .exe-extension in the same directory 2) since libtool does this, do not use libtool and transparent_exe together. Not the greatest situation, but we lived with it. Backgrounders: http://cygwin.com/ml/cygwin/2006-03/msg00148.html http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html http://cygwin.com/ml/cygwin/2007-04/msg00543.html But then, along comes cygwin-1.7...in which 'transparent_exe' will be the default behavior. Oops. Don't use libtool and cygwin-1.7 is not a rule we can live with. So, (and this is the part that broke the cross-builders), we changed libtool's behavior... 3 == About two years ago, for $host cygwin/mingw, libtool was modified to no longer put a wrapper *script* in the build dir. Instead, it put an uglify-named version of it in .libs: my_prog.exe (not the real exe; just a wrapper exe) .libs/my_prog_ltshwrapper(the wrapper script #1) .libs/my_prog_ltshwrapperTMP (the wrapper script #2) .libs/my_prog.exe (the real exe) That way, no more 'transparent_exe' clashes. BUT, now the poor cross-builders have no wrapper script to execute. They have to
Re: file name too long
Paul Cantalupo wrote: Hello, I updated my cygwin installation to 1.5.25-15 but I'm still getting 'file name too long' errors when trying to extract a .tgz archive that contains some really long pathnames. Here is an example of one of the errors: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. Interestingly, even some of the files that 'tar' can extract, 'ls' returns an error when I try to see the contents of the directory: ls: cannot access S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file0.fa: File name too long I found this (http://www.cygwin.com/ml/cygwin-developers/2008-01/msg0.html) discussion of what seems to be the same problem that I am having. So, was a fix ever implemented? Is there a workaround to this problem other than installing Linux? Yes, it was implemented for the upcoming Cygwin 1.7 release, now in release testing: http://cygwin.com/ml/cygwin-announce/2009-02/msg00018.html -- 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/
special name for vss shadow copy device?
All, I'm familiar with http://www.cygwin.com/cygwin-ug-net/using-specialnames.html But it only shows the \device\hardisk mappings. Are there also mapppings for the shadow devices. (http://en.wikipedia.org/wiki/Shadow_Copy) ie. \Device\HarddiskVolumeShadowCopy4 or \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4 If your running Vista or Win2008 you can create a shadow copy device by going to the file explorer, right clicking on a local NTFS drive, clicking properties, then the shadow copies tab, then create now. To get the instance number (4 above) you go to the command line and type vssadmin list shadows. In theory I should be able to mount that under cygwin and access my snapshot-ed filesystem. My personal desire is make a full dd copy of a snapshot onto a external drive. ie. dd if=/dev/sd-shadowcopy4 of=my_image_file Thanks Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.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: wget, ssh, ssh-agent hang in socket_cleanup
I would be happy to try it. I'm currently running version - Paul1.5.25-15. How do I download version 1.7? Setup is giving me 1.5.25-14! - Paul Corinna Vinschen wrote: On Feb 22 18:24, Paul McFerrin wrote: I've been having the same problem for the past two weeks. Just didn't know where to look. Thanks for sharing. Maybe we can get someone on this. Wget would just HANG intermittently in the Connecting phase. I don't observe this problem. Does updating to Cygwin 1.7 help? Corinna -- 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: gcc compile problem: error: stray \168 in program
grip wrote:
Note: I have to type double quotes twice always and I
get two double quotes. I use backspace to remove one every time. A single
double quotes produces no output on the screen
This behaviour is coherent with the hypothesis that you're in fact using
the diaeresis key, and it seems to be a dead key on your keyboard.
What happens when you press:
- {mysterious key}+{space}. Do you get a single ¨ ?
- {mysterious key}+a. Do you get ä ? That is (if encoding of this key
get börked) an a plus two dots on top of it.
- {mysterious key}+e. Do you get ë ? (Same thing for e)
You may use the illustration in the Diaeresis wikipedia article [1]
useful (right sidebar).
[1] http://en.wikipedia.org/wiki/Diaeresis
Good luck,
--
Sylvain RICHARD
--
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: [CFT] libtool on nix-cygwin cross, with wine
On 2009-02-24 20:36Z, rhubbell wrote: What's the [CFT] stand for? Call For Test? Yes. He spelled it out: CALL FOR TEST By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU -- 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: file name too long
On Tue, 24 Feb 2009, Paul Cantalupo hey, I remembers to expunge this! wrote: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. I have a vague memory that the limit includes the current directory path. Anyone else know whether that's true or not? What's the current directory name when running that? If you add the length of the current directory name, plus one for the / separator, plus the length of the path above, is it more than 254? Is there a workaround to this problem other than installing Linux? When the problem can be helped with a shorter directory name, I use the subst Windows command to map the directory to a drive letter. That shortens the directory name from whatever to 2. For example, M: is one letter that I leave unused, and /mnt is my value instead of /cygdrive. So, as an untested example from Windows Server 2003: /mnt/c/WINDOWS/system32/subst M: 'c:\long\path name\goes here' pushd /mnt/m [do my work here] popd /mnt/c/WINDOWS/system32/subst M: /d# unmap the drive letter -- Tim McDaniel, t...@panix.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/
lynx seems broken
Hi, On my machine#2 I just installed lynx, but it just exit without telling anything. Then I went to my machine#1 where lynx was already installed, and it worked fine. I then ran setup.exe and it installed a little. After that, lynx just exit without telling anything. I attach cygcheck.out1 which is taken before the upgrade on machine#1 and cygcheck.out2 which is taken after the upgrade. Did I do anything wrong? Cheers, Morten $ diff cygcheck.out1 cygcheck.out2 3c3 Current System Time: Tue Feb 24 22:27:38 2009 --- Current System Time: Tue Feb 24 22:30:08 2009 181,182c181,182 40k 2006/11/15 C:\cygwin\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0 cygform-8.dll v0.0 ts=2006/11/15 8:06 --- 41k 2009/02/23 C:\cygwin\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0 cygform-8.dll v0.0 ts=2009/2/23 17:21 225,226c225,226 21k 2006/11/15 C:\cygwin\bin\cygmenu-8.dll - os=4.0 img=1.0 sys=4.0 cygmenu-8.dll v0.0 ts=2006/11/15 8:05 --- 21k 2009/02/23 C:\cygwin\bin\cygmenu-8.dll - os=4.0 img=1.0 sys=4.0 cygmenu-8.dll v0.0 ts=2009/2/23 17:20 235,236c235,236 67k 2006/11/15 C:\cygwin\bin\cygncurses++-8.dll - os=4.0 img=1.0 sys=4.0 cygncurses++-8.dll v0.0 ts=2006/11/15 8:13 --- 335k 2009/02/23 C:\cygwin\bin\cygncurses++-8.dll - os=4.0 img=1.0 sys=4.0 cygncurses++-8.dll v0.0 ts=2009/2/23 17:28 241,242c241,242 237k 2006/11/15 C:\cygwin\bin\cygncurses-8.dll - os=4.0 img=1.0 sys=4.0 cygncurses-8.dll v0.0 ts=2006/11/15 8:02 --- 161k 2009/02/23 C:\cygwin\bin\cygncurses-8.dll - os=4.0 img=1.0 sys=4.0 cygncurses-8.dll v0.0 ts=2009/2/23 17:18 249,250c249,250 12k 2006/11/15 C:\cygwin\bin\cygpanel-8.dll - os=4.0 img=1.0 sys=4.0 cygpanel-8.dll v0.0 ts=2006/11/15 8:04 --- 11k 2009/02/23 C:\cygwin\bin\cygpanel-8.dll - os=4.0 img=1.0 sys=4.0 cygpanel-8.dll v0.0 ts=2009/2/23 17:19 278a279,280 66k 2009/02/23 C:\cygwin\bin\cygtic-8.dll - os=4.0 img=1.0 sys=4.0 cygtic-8.dll v0.0 ts=2009/2/23 17:15 320c322 _update-info-dir 00802-1 --- _update-info-dir 00807-1 378c380 libncurses8 5.5-3 --- libncurses8 5.7-1 395c397 ncurses 5.5-3 --- ncurses 5.7-1 408c410 terminfo 5.5_20061104-1 --- terminfo 5.7_20090221-1 $ cygcheck.out1 Description: Binary data cygcheck.out2 Description: Binary data -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. -- 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: file name too long
On Tue, Feb 24, 2009 at 4:27 PM, Tim McDaniel t...@panix.com wrote: On Tue, 24 Feb 2009, Paul Cantalupo hey, I remembers to expunge this! wrote: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. I have a vague memory that the limit includes the current directory path. Anyone else know whether that's true or not? The issue is definitely an issue with the full path length. There may also be a max filename length, but I have not come across it. Is there a workaround to this problem other than installing Linux? Since your just trying to extract a tar file, create a directory c:/a then cd into it and try to extract from there. We use that trick fairly often. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, Feb 24, 2009 at 4:35 PM, rhubbell rhubb...@ihubbell.com wrote: On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.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: [CFT] libtool on nix-cygwin cross, with wine
Greg Freemyer wrote: On Tue, Feb 24, 2009 at 4:35 PM, rhubbell rhubb...@ihubbell.com wrote: On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. What still always makes me laugh is the people who are so emphatic about top vs. bottom posting. (someone even had a clever .sig showing the flow of top posting and how backwards it is) But honestly, we humans have remarkable brains that let us put back together the conversation in either order. Is it really *that* hard? Maybe for some. But what made me laugh about the .sig was that it missed something. it said something along the idea of: Because it just does. Why. Yes. So, does that make it evil? because it reverses the flow of discussion. why is top posting evil? But what makes me laugh is that people on a list have now just received a sequence of messages in the correct flow with the most current information at the top without the need for scrolling through redundant previous message info just to get to the goods at the bottom. Personally (and this is the important part), I don't let it bother *me* because I realize everyone's brain works a little differently. Speaking of which.. http://mailformat.dan.info/quoting/top-posting.html Sorry for my ramble. I'll go hide now. -Ben -- Ben Kamen - O.D.T., S.P. = Email: bkamen AT benjammin DOT net Web: http://www.benjammin.net As seen somewhere on the net: My other computer is your Windows Server. -- 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: wget, ssh, ssh-agent hang in socket_cleanup
Paul McFerrin wrote: I would be happy to try it. I'm currently running version - Paul1.5.25-15. How do I download version 1.7? Setup is giving me 1.5.25-14! As expected. If you want 1.7, go to the cygwin-announce mailing list and read one of the (preferably the latest) 1.7 announcements to find out how to install it. -- 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: [CFT] libtool on nix-cygwin cross, with wine
Ben Kamen wrote: snip But what made me laugh about the .sig was that it missed something. it said something along the idea of: Because it just does. Why. Yes. So, does that make it evil? because it reverses the flow of discussion. why is top posting evil? I had to laugh when I saw this! In any case, since you felt it important to call out my sig, I figured I'd respond to get the actual text as part of this (hopefully very short-lived) thread. See it below. And in case anyone is wondering, I am not the author of the sig, I just use it. -- 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: [CFT] libtool on nix-cygwin cross, with wine
rhubbell wrote: On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. Thanks for sharing. Well, of course, if this bothers you to some great extent, you need not stay. We won't follow you home. Promise! :-) -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, 24 Feb 2009 18:12:00 -0500 Larry Hall (Cygwin) wrote: Thanks for sharing. Well, of course, if this bothers you to some great extent, you need not stay. We won't follow you home. Promise! :-) Thank you too for sharing. (^: -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, 24 Feb 2009 17:45:21 -0500 Ben Kamen wrote: What still always makes me laugh is the people who are so emphatic about top vs. bottom posting. If born sooner they would be shouting Get of my lawn!. -- 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/
graphics programming - beginner
Hi, The previous message I asked was the path to graphics.h library but it seems to get more confusion. After searching for awhile, it seems that the graphics.h library is obsoleted. I try to compile some simple graphics program but unsure what libraries to #include and what compile parameters are needed. If someone shows me or has a link to someplace where it has some simple program, and step by step to compile it to run under cygwin, I appreciate it. Thank you. HLe -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, Feb 24, 2009 at 04:44:58PM -0600, Ben Kamen wrote: Greg Freemyer wrote: On Tue, Feb 24, 2009 at 4:35 PM, rhubbell rhubb...@ihubbell.com wrote: On Tue, 24 Feb 2009 16:15:33 -0500 Greg Chicares wrote: By the way, this list discourages full quoting: http://www.cygwin.com/acronyms/#TOFU Ok, this is one neurotic list. A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. What still always makes me laugh is the people who are so emphatic about top vs. bottom posting. (someone even had a clever .sig showing the flow of top posting and how backwards it is) But honestly, we humans have remarkable brains that let us put back together the conversation in either order. Is it really *that* hard? Maybe for some. But what made me laugh about the .sig was that it missed something. it said something along the idea of: Because it just does. Why. Yes. So, does that make it evil? because it reverses the flow of discussion. why is top posting evil? But what makes me laugh is that people on a list have now just received a sequence of messages in the correct flow with the most current information at the top without the need for scrolling through redundant previous message info just to get to the goods at the bottom. Personally (and this is the important part), I don't let it bother *me* because I realize everyone's brain works a little differently. Speaking of which.. http://mailformat.dan.info/quoting/top-posting.html Sorry for my ramble. I'll go hide now. Thanks. Your notion that you have anything new to say on this subject is very wrong. And, since your ramble has nothing to do with Cygwin, you're also off-topic. If people want a forum to demonstrate their ability to laugh at odd things or to express sentiments about the culture of this list then maybe the cygwin-talk mailing list would be more to their liking. -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, 24 Feb 2009 17:33:53 -0500 Greg Freemyer greg.freem...@gmail.com wrote: A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. I was mostly noticing how frequent the list policing is here. And also what hypocrites there are too. Look at your .sig, a lot of useless information, but you send it every time. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.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/ -- 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/
[OT] Re: [CFT] libtool on nix-cygwin cross, with wine
rhubbell wrote: I was mostly noticing how frequent the list policing is here. How frequently you notice it may be different from how frequently other people notice it, hopefully in proportion to whether you are more or less of a jerk than whichever other people you choose to compare yourself against. And also what hypocrites there are too. Look at your .sig, a lot of useless information, but you send it every time. It's a fraction of the useless information that you send every time by always duplicating the entire previous post. Just how many times do you need to see that list of URLs anyway? It certainly creates the impression that you believe that your wit and wisdom is of such great value that your every trivial and inconsequential thought must be broadcast to the world at large the moment it pours forth from your imagination, a matter of such earth-shattering import that we would not want to wait the three seconds it would take you to trim the spam from your post. This is why you're getting the treatment: you come across to have an overly-high opinion of your own worth. FTR, I'd be happy to wait that extra 3 seconds. DaveK. -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, Feb 24, 2009 at 07:05:05PM -0800, rhubbell wrote: On Tue, 24 Feb 2009 17:33:53 -0500 Greg Freemyer greg.freem...@gmail.com wrote: A lot of Linux mailing lists have that policy. Especially if it is high volume or has a large subscriber base. The idea is that someone can read a single email and understand it without having to bounce all over the place. I was mostly noticing how frequent the list policing is here. And also what hypocrites there are too. Look at your .sig, a lot of useless information, but you send it every time. What you notice is not of any interest here. Please stop this off-topic discussion. Warning #1. -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, 24 Feb 2009 22:32:23 -0500 Christopher Faylor wrote: Please stop this off-topic discussion. Warning #1. I'll stop if you do. Warning #1. -- 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: wget, ssh, ssh-agent hang in socket_cleanup
I tried updating cygwin1.dll up to version 1.7 on my production system and it (system) failed to start. So I backed it out for now unless someone can give me some help is upgrading to 1.7 as I have NO experience with 1.7. Here are my errors: Huh? No /etc/fstab file in \??\C:\cygwin\etc\fstab.d\Paul? Using default root and cygdrive prefix... cygwin warning: MS-DOS style path detected: C:/cygwin/home/paul/.bash_login Preferred POSIX equivalent is: /home/paul/.bash_login CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames ksh: C:/cygwin/home/paul/.bash_login[5]: /usr/bin/ksh: not found mount (1.5 output) C:\cygwin\bin on /bin type system (binmode) C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\etc on /etc type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin\lib on /lib type system (binmode) C:\cygwin\usr on /usr type system (binmode) C:\cygwin\u on /u type system (binmode) C:\cygwin on / type system (binmode) \\linda\c on /pc type system (binmode) C: on /c type system (binmode) D: on /d type system (binmode) E: on /e type system (binmode) F: on /f type system (binmode) G: on /g type system (binmode) H: on /h type system (binmode) I: on /i type system (binmode) J: on /j type system (binmode) K: on /k type system (binmode) L: on /l type system (binmode) M: on /m type system (binmode) N: on /n type system (binmode) O: on /o type system (binmode) P: on /p type system (binmode) Q: on /q type system (binmode) a: on /a type system (binmode) Questions: 1. Why is it looking for fstab under \??\C:\cygwin\etc\fstab.d\Paul? 2. I get a warning accessing a letter drive number?? Looks like some more reading before trying again. How stable is 1.7? I would like to leave it running in production mode. Paul P.S. I don't have the luxary of bringing down a production system to debug a new release at this time. Corinna Vinschen wrote: On Feb 22 18:24, Paul McFerrin wrote: I've been having the same problem for the past two weeks. Just didn't know where to look. Thanks for sharing. Maybe we can get someone on this. Wget would just HANG intermittently in the Connecting phase. I don't observe this problem. Does updating to Cygwin 1.7 help? Corinna -- 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: [OT] Re: [CFT] libtool on nix-cygwin cross, with wine
On Tue, 24 Feb 2009 22:22:05 -0500 Dave Korn wrote: How frequently you notice it may be different from how frequently other people notice it, hopefully in proportion to whether you are more or less of a jerk than whichever other people you choose to compare yourself against. You seemed to have taken note. You have a delete button, right? And also what hypocrites there are too. Look at your .sig, a lot of useless information, but you send it every time. It's a fraction of the useless information that you send every time by always duplicating the entire previous post. Just how many times do you need to see that list of URLs anyway? It certainly creates the impression that you believe that your wit and wisdom is of such great value that your every trivial and inconsequential thought must be broadcast to the world at large the moment it pours forth from your imagination, a matter of such earth-shattering import that we would not want to wait the three seconds it would take you to trim the spam from your post. This is why you're getting the treatment: you come across to have an overly-high opinion of your own worth. You're certainly happy with yourself, don't believe everything you think. FTR, I'd be happy to wait that extra 3 seconds. An exemplary hypocrite. Hall-o-famer. If only you could practice what you spew. -- 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: [CFT] libtool on nix-cygwin cross, with wine
On Tue, Feb 24, 2009 at 07:40:31PM -0800, rhubbell wrote: On Tue, 24 Feb 2009 22:32:23 -0500 Christopher Faylor wrote: Please stop this off-topic discussion. Warning #1. I'll stop if you do. Warning #1. Ok, so long then. 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/
Updated: astyle-1.23-1
I've uploaded a new version astyle, 1.23-1, in keeping with the current upstream release. Note: This release is for Cygwin 1.7.x only, there is no release for Cygwin 1.5.x at this point. For a list of changes check out http://astyle.sourceforge.net/astyle_release_notes.html. 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 answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cyg...@cygwin.com . *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Chris -- Chris Sutcliffe http://emergedesktop.org
