[RFU] mpfr-2.4.1-1 for cygwin 1.5
I have a cygwin 1.5 build of mpfr-2.4.1 for available for upload. I expect this will be the final
build for 1.5. It just contains a few bug fixes from upstream. The setup.hint files are unchanged.
The package builds OOTB and pass all tests in the testsuites.
D=http://billinghurst.customer.netspace.net.au/cygwin
mkdir mpfr
cd mpfr
wget ${D}/mpfr/mpfr-2.4.1-1-src.tar.bz2
wget ${D}/mpfr/mpfr-2.4.1-1.tar.bz2
wget ${D}/mpfr/setup.hint
mkdir libmpfr-devel
cd libmpfr-devel
wget ${D}/mpfr/libmpfr-devel/libmpfr-devel-2.4.1-1.tar.bz2
wget ${D}/mpfr/libmpfr-devel/setup.hint
cd ..
mkdir libmpfr1
cd libmpfr1
wget ${D}/mpfr/libmpfr1/libmpfr1-2.4.1-1.tar.bz2
wget ${D}/mpfr/libmpfr1/setup.hint
cd ../..
[RFU] mpfr-2.4.1-2 for cygwin 1.7
I have a cygwin 1.7 build of mpfr-2.4.1 for available for upload. This is the first build for 1.7
It just contains a few bug fixes from upstream. The setup.hint files are unchanged.
The package builds OOTB and pass all tests in the testsuites.
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
mkdir mpfr
cd mpfr
wget ${D}/mpfr/mpfr-2.4.1-2-src.tar.bz2
wget ${D}/mpfr/mpfr-2.4.1-2.tar.bz2
wget ${D}/mpfr/setup.hint
mkdir libmpfr-devel
cd libmpfr-devel
wget ${D}/mpfr/libmpfr-devel/libmpfr-devel-2.4.1-2.tar.bz2
wget ${D}/mpfr/libmpfr-devel/setup.hint
cd ..
mkdir libmpfr1
cd libmpfr1
wget ${D}/mpfr/libmpfr1/libmpfr1-2.4.1-2.tar.bz2
wget ${D}/mpfr/libmpfr1/setup.hint
cd ../..
Re: [RFU] mpfr-2.4.1-2 for cygwin 1.7
On Mar 2 22:36, David Billinghurst wrote:
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
mkdir mpfr
cd mpfr
wget ${D}/mpfr/mpfr-2.4.1-2-src.tar.bz2
wget ${D}/mpfr/mpfr-2.4.1-2.tar.bz2
wget ${D}/mpfr/setup.hint
mkdir libmpfr-devel
cd libmpfr-devel
wget ${D}/mpfr/libmpfr-devel/libmpfr-devel-2.4.1-2.tar.bz2
wget ${D}/mpfr/libmpfr-devel/setup.hint
cd ..
mkdir libmpfr1
cd libmpfr1
wget ${D}/mpfr/libmpfr1/libmpfr1-2.4.1-2.tar.bz2
wget ${D}/mpfr/libmpfr1/setup.hint
cd ../..
Uploaded.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [RFU] mpfr-2.4.1-1 for cygwin 1.5
On Mar 2 22:35, David Billinghurst wrote:
D=http://billinghurst.customer.netspace.net.au/cygwin
mkdir mpfr
cd mpfr
wget ${D}/mpfr/mpfr-2.4.1-1-src.tar.bz2
wget ${D}/mpfr/mpfr-2.4.1-1.tar.bz2
wget ${D}/mpfr/setup.hint
mkdir libmpfr-devel
cd libmpfr-devel
wget ${D}/mpfr/libmpfr-devel/libmpfr-devel-2.4.1-1.tar.bz2
wget ${D}/mpfr/libmpfr-devel/setup.hint
cd ..
mkdir libmpfr1
cd libmpfr1
wget ${D}/mpfr/libmpfr1/libmpfr1-2.4.1-1.tar.bz2
wget ${D}/mpfr/libmpfr1/setup.hint
cd ../..
Uploaded.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
[RFU] gmp-4.2.4-2 for cygwin 1.7
I have a build of gmp-4.2.4 for cygwin 1.7 available for upload.
This is the first build for cygwin-1.7. There are a couple of changes
from gmp-4.2.4-1 (for cygwin-1.5)
1) The DLL for C++ binding libgmpxx3 is in a separate sub-package
as we will need to bump the version number once g++-4 is the system
compiler. This establishes a legacy package for g++-3.
2) There are three patches from http://gmplib.org/
[2008-12-26] The function mpz_perfect_power_p does not work correctly
for negative arguments, but rejects many negative perfect powers.
[2008-11-09] When calling mpf_set_str (perhaps indirectly via
mpf_init_set_str or mpf_inp_str, or via the C++ interface) with the
argument for the base set to 0, any exponent will be ignored. Patch
[2008-11-08] The mpf_eq function sometimes compares too few bits, not
just too many (the latter is documented). This might lead to precision loss.
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
mkdir gmp
cd gmp
wget ${D}/gmp/gmp-4.2.4-2-src.tar.bz2
wget ${D}/gmp/gmp-4.2.4-2.tar.bz2
wget ${D}/gmp/setup.hint
mkdir libgmp-devel
cd libgmp-devel
wget ${D}/gmp/libgmp-devel/libgmp-devel-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp-devel/setup.hint
cd ..
mkdir libgmp3
wget ${D}/gmp/libgmp3/libgmp3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp3/setup.hint
cd ..
mkdir libgmp3xx
wget ${D}/gmp/libgmp3xx/libgmp3xx-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp3xx/setup.hint
cd ../..
Re: [RFU] gmp-4.2.4-2 for cygwin 1.7
Hi David,
there's a problem with libgmp3xx:
On Mar 2 22:49, David Billinghurst wrote:
mkdir libgmp3
wget ${D}/gmp/libgmp3/libgmp3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp3/setup.hint
cd ..
mkdir libgmp3xx
wget ${D}/gmp/libgmp3xx/libgmp3xx-4.2.4-2.tar.bz2
12:02:12 ERROR 404: Not Found.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [RFU] gmp-4.2.4-2 for cygwin 1.7
Corinna Vinschen wrote:
Hi David,
there's a problem with libgmp3xx:
On Mar 2 22:49, David Billinghurst wrote:
mkdir libgmp3
wget ${D}/gmp/libgmp3/libgmp3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp3/setup.hint
cd ..
mkdir libgmp3xx
wget ${D}/gmp/libgmp3xx/libgmp3xx-4.2.4-2.tar.bz2
12:02:12 ERROR 404: Not Found.
Corinna
Sorry. s/3xx/xx3/ in the last few lines AND missing cd libgmp3.
I should have written:
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
mkdir gmp
cd gmp
wget ${D}/gmp/gmp-4.2.4-2-src.tar.bz2
wget ${D}/gmp/gmp-4.2.4-2.tar.bz2
wget ${D}/gmp/setup.hint
mkdir libgmp-devel
cd libgmp-devel
wget ${D}/gmp/libgmp-devel/libgmp-devel-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp-devel/setup.hint
cd ..
mkdir libgmp3
cd libgmp3
wget ${D}/gmp/libgmp3/libgmp3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp3/setup.hint
cd ..
mkdir libgmpxx3
cd libgmpxx3
wget ${D}/gmp/libgmpxx3/libgmpxx3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmpxx3/setup.hint
cd ../..
Re: [RFU] gmp-4.2.4-2 for cygwin 1.7
On Mar 2 23:19, David Billinghurst wrote:
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
mkdir gmp
cd gmp
wget ${D}/gmp/gmp-4.2.4-2-src.tar.bz2
wget ${D}/gmp/gmp-4.2.4-2.tar.bz2
wget ${D}/gmp/setup.hint
mkdir libgmp-devel
cd libgmp-devel
wget ${D}/gmp/libgmp-devel/libgmp-devel-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp-devel/setup.hint
cd ..
mkdir libgmp3
cd libgmp3
wget ${D}/gmp/libgmp3/libgmp3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmp3/setup.hint
cd ..
mkdir libgmpxx3
cd libgmpxx3
wget ${D}/gmp/libgmpxx3/libgmpxx3-4.2.4-2.tar.bz2
wget ${D}/gmp/libgmpxx3/setup.hint
cd ../..
Uploaded.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
src/winsup/utils ChangeLog mount.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-03-02 10:47:04 Modified files: winsup/utils : ChangeLog mount.cc Log message: * mount.cc (mount_entries): Handle a / cygdrive prefix correctly. Add comments. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.448r2=1.449 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/mount.cc.diff?cvsroot=srcr1=1.43r2=1.44
src/winsup/utils ChangeLog utils.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-03-02 10:56:20 Modified files: winsup/utils : ChangeLog utils.sgml Log message: * utils.sgml: Set example prompt to $ throughout. Don't use / as example cygdrive prefix. Remove reference to -u and -s options. Add an example using the -o flag. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.449r2=1.450 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/utils.sgml.diff?cvsroot=srcr1=1.71r2=1.72
[Patch] gethostbyname2 again
Corinna, OK, here we go again. This version calls res_query and all the work is done in net.cc. As discussed before that means a lot of work is wasted when using the Windows resolver. That will be improved later. There is no progress on the issue of resolving local names (NetBIOS over TCP) for now, so it's not a perfect replacement for the native gethostbyname yet. Misc nits and notes: - Including resolv.h in net.cc causes havoc because it pulls in cygwin/in.h which conflicts with winsock2.h. I worked around that by defining _CYGWIN_IN_H before including resolv.h - Because of the above, asm/byteorder.h doesn't get pulled in either, and I couldn't use some ntoh macros (see memcpy4to6). - I could have included asm/byteorder separately but that causes conflicts with the local ntoh definitions in net.cc. - Because arpa/nameser.h is now pulled in, IN6ADDRSZ etc are now defined, but in a way different from done in the snippet of code cut pasted from bind. I didn't want to change that piece (in case you want to keep in intact for some reason) and I ended up undefining IN6ADDRSZ etc . - There is a new helper function dn_length1 which logically belongs in minires.c, although it shouldn't be exported by the dll. However if I place it in minires.c, then the linker doesn't find it. Fixing that probably involves some Makefile magic. - I structured the code with a helper function gethostby_helper. That will make it very easy to support a gethostbyaddress some day, if needed. - The helper function avoids using dup_ent (there is enough copying already). I created a new realloc_ent function, and call it from both dup_ent and the helper. That caused minor changes in the 4 versions of dup_ent, and I don't know exactly what format to use in the ChangeLog - This is much more complex than the first way of doing things. Needs testing! - The patch is long, see the attachment. There is also a test program attached. Pierre 2009-03-02 Pierre Humblet pierre.humb...@ieee.org * net.cc: define _CYGWIN_IN_H and include resolv.h. (realloc_ent): New function. (dup_ent): Remove dst argument and call realloc_ent. (memcpy4to6): New function. (dn_length1): New function. (gethostby_helper): New function. (gethostbyname2): New function. * cygwin.din: Export gethostbyname2. * libc/minires.c (get_options): Look for inet6 and apply bounds to retry and retrans. (res_ninit): Set the default options at the beginning. (dn_expand): Fix off by one. gethostbyname2_b.diff Description: Binary data try_gethostbyname.c Description: Binary data
Re: Fw: patch command giving permission denied
On Mar 1 23:08, Sjors Gielen wrote: Aaron Gray schreef: On Sat, Feb 28, 2009 at 1:30 AM, Aaron Gray aaronngray.li...@googlemail.com wrote: I am getting the following on executing the patch command :- bash: /usr/bin/patch: Permission Denied It works on my other Vista machine okay (That is an Enterprise one rather than a Home version) Anyone got any ideas why and how to fix it It works fine on my other Vista Home machine. It works okay if I run cygwin bash as an administrator. Why is this machine behaving differently and how do I fix it ? I tried reloading Cygwin from scratch, but that did not help. Aaron I had this problem too. It's because of the new UAC in Windows. You need to add a .manifest file, because patch.exe contains one of install, setup and patch, which UAC does not trust right away. It's The latest patch package 2.5.8-9 comes already with a manifest file. 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: umount/mount issues
On Mar 1 20:40, Karl M wrote: For cygwin umount, -v is version display (-V on Linux? -v is verbose). That's the same for mount. There's no verbosity for these commands anyway. For mount -m I get the following $ mount -m C:/Cygwin/bin /usr/bin ntfs binary 0 0 C:/Cygwin/lib /usr/lib ntfs binary 0 0 C:/Cygwin / ntfs binary 0 0 none /c cygdrive binary,posix=0 0 0 where the /c in the last line should be / This came from an fstab of (I know...I have done the evil / prefix for years and am hooked.) Sigh. Why are you guys insisting on using this prefix. I fixed mount to show this correctly, but you still should feel guilty. Other than that, things worked great so far. It is wonderful to see all of my Cygwin processes again after moving to Vista. Yeah, I'm quite pleased with this one, too. Hopefully Microsoft won't restrict this specific usage of global shared memory in a later Windows release again. 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: umount/mount issues
On Mar 1 22:21, Karl M wrote: Hi All... I also noticed in the Cygwin 1.7 user guide that just after example 3.11 the non-existant -s and -u options are referenced. Fixed. And more. While fixing the above it occured to me that the example cygdrive prefix used in the example is ... / *blush* 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: umount/mount issues
On Mar 2 12:04, Corinna Vinschen wrote: On Mar 1 22:21, Karl M wrote: Hi All... I also noticed in the Cygwin 1.7 user guide that just after example 3.11 the non-existant -s and -u options are referenced. Fixed. And more. While fixing the above it occured to me that the example cygdrive prefix used in the example is ... / *blush* Btw, I uploaded the fixed doc to http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html Please take a look. Thanks, 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: console scroll speed on Win XP
Andy Yep, the Windows console is slow alright, and I don't know of any way Huh? The windows console is fast, among the fastest I have ever used, BUT you must have the video driver for your specific card. If you just have the generic VGA driver, it is slow, and other things are noticably too. I haven't seen a faster graphical console, but text consoles are also fast. Also being in bash seems slower. I usually set PATH=c:\cygwin\bin;%PATH% but don't use bash interactively. You might try that. Being in cmd preserves the nice F8 command line completion against history feature that I haven't found elsewhere. - Jay -- 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 28 21:28, Corinna Vinschen wrote: On Feb 28 14:51, Christopher Faylor wrote: On Sat, Feb 28, 2009 at 01:47:16PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: If so, I'm wondering if setting the TS-aware flag shouldn't become default in GCC. What do you say, Dave? Would that be possible? I'd probably wait on that for the /next/ release (e.g. after 4.3.2-2), [...] Maybe the aslr functionality is different enough -- and useful in enough contexts that differ from rebasing -- that instead of incorporating 'call aslr TOO' into rebaseall, there should be a separate 'aslrall' script? It should be trivial to add this to binutils. Doesn't it ultimately belong in ld and (maybe) objcopy? Yes, that should be done in ld. I can add this now but I don't think it should be the default just yet. If the TS-aware flag actually helps to avoid the tsappcmp.dll bug, then I think the flag should be set by ld by default for Cygwin apps. Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. 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] Editing in /etc
Looks like it's related to some issue reading stdin... I executed vim
in debug mode ('vim -D passwd') and got the following:
Fixed... I messed up the permissions in my /dev directory.
Perhaps I spoke to soon... I'm still having the issue, this time with
a domain based user.
I executed 'mkpasswd -l -c /etc/passwd' which again acted as
expected, and the /etc/passwd file was created. I went to edit the
file with 'vim -D /etc/passwd' to change the users' default group and
vim again displayed the message about an error opening input.
Looking in /dev I have:
drwxrwxrwt+ 1 ironhead Users 0 Dec 5 08:22 shm/
drwxrwxrwt+ 1 ironhead Users 0 Dec 5 08:22 mqueue/
lrwxrwxrwx 1 ironhead Users 15 Dec 5 08:22 stdin - /proc/self/fd/0
lrwxrwxrwx 1 ironhead Users 15 Dec 5 08:22 stdout - /proc/self/fd/1
lrwxrwxrwx 1 ironhead Users 15 Dec 5 08:22 stderr - /proc/self/fd/2
lrwxrwxrwx 1 ironhead Users 13 Dec 5 08:22 fd - /proc/self/fd/
(note that the domain user ID is 'csutclif' and 'ironhead' is the
local user ID that was giving me problems before).
Further checking on stdin reveals:
$ ls -ltr /proc/self/fd/0
lrwxrwxrwx 1 csutclif Users 0 Nov 30 2006 /proc/self/fd/0 - /dev/tty0
however, there is no /dev/tty0. Should there be? If so, how do I create it?
I'm at a loss here, could anybody hazard an idea as to what could be
happening, or how I could further debug the issue?
Thanx!
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/
Re: side effects after installing gcc-3.4.4.999
Greg Chicares gchica...@sbcglobal.net If gcc version 3.x is what you want, why not just downgrade from 3.4.4-999 to gcc-3.4.4-3? AIUI, the only difference between the two is something you don't want: That's what i did (downgraded). Still, i wanted to make someone aware of the fact that the update was the cause of a change in behaviour. Alternatively, you might prefer to use mingw.org's native gcc. I use both cygwin and mingw. cygwin have more programs and a better unix support. mingw has no dependance on a dedicated dll. -- 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] Editing in /etc
On Mar 2 08:36, Chris Sutcliffe wrote:
Looks like it's related to some issue reading stdin... I executed vim
in debug mode ('vim -D passwd') and got the following:
Fixed... I messed up the permissions in my /dev directory.
Perhaps I spoke to soon... I'm still having the issue, this time with
a domain based user.
I can't reproduce that, neither from a console window, nor from a mintty
window.
I executed 'mkpasswd -l -c /etc/passwd' which again acted as
expected, and the /etc/passwd file was created. I went to edit the
file with 'vim -D /etc/passwd' to change the users' default group and
vim again displayed the message about an error opening input.
So this does not only occur in /etc? What happens if you start vim
without the -D flag?
Looking in /dev I have:
The content of /dev shouldn't matter, in theory.
$ ls -ltr /proc/self/fd/0
lrwxrwxrwx 1 csutclif Users 0 Nov 30 2006 /proc/self/fd/0 - /dev/tty0
however, there is no /dev/tty0. Should there be? If so, how do I create it?
http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices
I'm at a loss here, could anybody hazard an idea as to what could be
happening, or how I could further debug the issue?
Maybe something in /etc is making problems but I can't imagine what that
is. This is a typical case where you just have to debug this. Strace
might reveal a problem here. Or maybe it's a BLODA problem.
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: console scroll speed on Win XP
From: jay.kr...@cornell.edu To: cygwin@cygwin.com; marchy...@hotmail.com; andy.ko...@gmail.com Subject: RE: console scroll speed on Win XP Date: Mon, 2 Mar 2009 11:34:08 + Andy Yep, the Windows console is slow alright, and I don't know of any way Huh? The windows console is fast, among the fastest I have ever used, BUT you must have the video driver for your specific card. I'm on a laptop and don't have a card, a Compaq Evo N610c with XP pro. I tried to update drivers from HP with no obvious effect. In any case mintty was a lot faster with no obvious drawbacks yet. I can appreciate there may be some issues but using the whole CPU while it scrolled by a rate just fast enough for reading seemed a bit odd. mintty is unreadably fast and probably some of cpu time goes to disk IO in my benchmark taskamanager test with cat :) IIRC, dir on a 4 Megahertz Z-80 computer was at least as fast. If you just have the generic VGA driver, it is slow, and other things are noticably too. I haven't seen a faster graphical console, but text consoles are also fast. Also being in bash seems slower. I usually set PATH=c:\cygwin\bin;%PATH% but don't use bash interactively. You might try that. Being in cmd preserves the nice F8 command line completion against history feature that I haven't found elsewhere. - Jay -- 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/ _ Windows Live™ Contacts: Organize your contact list. http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009 -- 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: side effects after installing gcc-3.4.4.999
Akakima wrote: cygwin have more programs and a better unix support. ...which you refuse to use. I don't think you're going to get a whole lot of sympathy for your problem -- and I'm sure Dave is not going to respin gcc-3.4.4-999 to fix it. -- Chuck -- 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
Corinna Vinschen wrote: Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. like perhaps a repeatable option --peflags=[+-]tsaware|[+-]aslr|[+-]nx|[+-]wstrim (note that not all of these flags affect the same field in the pe header). or something even more generic but more powerful, WAY more dangerous, and harder to use, like --pehdrval=fieldname,hexval -- Chuck -- 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: side effects after installing gcc-3.4.4.999
Dave Korn wrote:
Nope, of course not. Use gcc-3.exe instead.
Dave, English is not my native language (I guess you know that!)
So i want to add that i am not critisizing
but just stating what i want and what i found. :-)
Why of course ?. You said in a previous post that the update would
go
without change in behaviour. I do not want to use gcc-3.exe.
I have many .bat/.cmd files calling gcc and i do not want to modify
them.
I still want to be able to call gcc.
and now if i type gcc, cmd finds gcc-3.exe and launch it.
That didn't work when I tried it:
C:\cygwin\etc\alternativesgcc
Access is denied.
Sorry, i dont know why. I assure you it works on my computer.
The are many entries in the WIndows registry to support shortcuts.
May be one of these entries is not ok on your machine.
C:\cygwin\etc\alternativesgcc.lnk
Access is denied.
C:\cygwin\etc\alternatives
But, this is not perfect. gcc (or someone else) wait until i press
enter to continue.
GCC doesn't do that sort of thing. What actual command do you
type, and
what symptom do you get? What program is running if you check with
ps -a in
another window while this possible wait-to-press-enter is occurring?
Does GCC
go ahead and generate a compiled output after you press enter?
the two commands:
gcc
gcc --version
ask for an enter.
The command: gcc file.c
does generate a.exe without asking for an enter.
I dont know why but will do some more checks.
The problem arises because you insist on two things: 1) you want to
use
cmd.exe, 2) you want to start a program without typing the name it's
actually
called. Since cmd.exe doesn't understand links, your two
requirements are
mutually contradictory. The best solution is to downgrade, or to
copy
gcc-3.exe to gcc.exe and get rid of the link stuff altogether.
Yes i want to use cmd.exe. This is ok i think.
And i want to type gcc not ggc-3. (lots of .bat files with gcc.exe
refs)
cmd.exe does understand links. I just reinstalled the update.
Now, if i type (under cmd.exe):
E:\cygwinE:\cygwin\etc\alternatives\gcc.lnk
E:\cygwingcc-3: no input files
--- waiting for an enter here. Enter does gives me the next line.
E:\cygwin
Compiling works without asking for an enter:
E:\cygwintype a.c
int main( ){return 0;}
E:\cygwinE:\cygwin\etc\alternatives\gcc.lnk a.c
E:\cygwindir a*
2009-03-02 09:0822 a.c
2008-08-30 18:03 8 904 a.exe
E:\cygwin
Adding .LNK to PATHEXT and e:\cygwin\etc\alternatives to PATH
allow me to type gcc from any directory. Windows will try
gcc.bat, gcc.cmd, gcc.exe, gcc.lnk in all the directories in the PATH.
Now, i am not saying this is a bug in cygwin. Again, i just want to
make someone
aware of the fact this is not without change in behaviour.
After i updated my installation with setup.exe (ran it without
selecting
anything and got the new gcc's automatically), i was surprise to
see that gcc.exe was not working anymore.
For the moment, i undone the update. Later i will find something else.
(Like copy gcc-3.exe gcc.exe).
And if i want to use both gcc3 and gcc4, i will probably use a couples
of bat files that will switch things around.
Thanks for your attention.
--
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: side effects after installing gcc-3.4.4.999
Charles Wilson ...which you refuse to use. I don't think you're going to get a whole lot of sympathy for your problem -- and I'm sure Dave is not going to respin gcc-3.4.4-999 to fix it. -- Chuck Ok. I was not asking for gcc being respined. Thanks anyway. -- 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] [1.7] Updated: {ncurses/libncurses-devel/ncurses-demo}-5.7-11; New: libncurses9-5.7-11
NOTE TO MAINTAINERS: You may need to add -ltinfo to LIBS when linking against ncurses. Given that tgetent has moved to libtinfo, I've configured vim using: LIBS=-Wl,--enable-auto-import ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir='$(sbindir)' \ --localstatedir=/var \ --datadir='$(prefix)/share' \ --mandir='$(prefix)/share/man' \ --enable-multibyte \ --without-x \ --enable-gui=no \ --with-features=huge \ --with-tlib=tinfo Building vim completes without error. However, when I try and execute the new vim.exe, I get: Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault Checking vim.exe: $ cygcheck src/vim.exe C:\cygwin-1.7\usr\src\vim\vim7\src\vim.exe C:\cygwin-1.7\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin-1.7\bin\cygtinfo-9.dll Is there something I'm missing? 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/
Re: umount/mount issues
On Mon, 2 Mar 2009, Corinna Vinschen wrote: On Mar 1 20:40, Karl M wrote: This came from an fstab of (I know...I have done the evil / prefix for years and am hooked.) Sigh. Why are you guys insisting on using this prefix. Is that a rhetorical question, or would you like people's answers? -- 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: umount/mount issues
On Mon, Mar 02, 2009 at 09:31:04AM -0600, Tim McDaniel wrote: On Mon, 2 Mar 2009, Corinna Vinschen wrote: On Mar 1 20:40, Karl M wrote: This came from an fstab of (I know...I have done the evil / prefix for years and am hooked.) Sigh. Why are you guys insisting on using this prefix. Is that a rhetorical question, or would you like people's answers? I'm sure it was rhetorical. We don't need another paean to the joy of using / as the cygdrive prefix. It's implemented, so there is no need to convince anyone. -- 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: SSH/SCREEN/REATTACH bug
Hello Andrew I just did a quick test so far but it doesn't seem to work correctly. The behaviour changed to the following: I open a screen session - and disconnect (not detach!) from the ssh session. I come back with screen -DRR and I get my old screen. That's *good* and how I want it. However if I start a program within the screen i.e. ping something forever I don't get the session back that way. Instead the old session will look dead and a new screen will open :( Thx for trying tho. eval. Andrew Schulman-3 wrote: screen hangs when attempting to reattach to a session that wasn't manually detached but instead the ssh connection to the server where screen is running was closed. i can neither screen -list nor screen -D -RR to get back into the session. for both calls screen will wait forever but nothing will happen. strace screen -list will stop here: 329 136923 [main] screen 137852 fhandler_socket::af_local_send_secret: Sending af_local secret succeeded eval, I've packaged a new test release of screen for Cygwin 1.7. This version uses fifos instead of pipes. It's possible that this change may fix the problem you reported. If you want to test it, here's what you'll have to do: (1) Install the latest Cygwin DLL snapshot into your Cygwin 1.7 installation. You can download it from http://cygwin.com/snapshots/cygwin1-20090226.dll.bz2, or from the Cygwin snapshot page, http://cygwin.com/snapshots. You need the 2009-02-26 snapshot or later. Once you have that, close all of your Cygwin 1.7 processes, go to the bin directory of your 1.7 installation, move cygwin1.dll out of the way, unpack the archive, and rename e.g. cygwin1-20090226.dll to cygwin1.dll. (2) Get and unpack the test screen installation: wget http://home.comcast.net/~andrex2/cygwin-1.7/screen/screen-4.0.3-4.tar.bz2 tar -C/ -jxf screen-4.0.3-4.tar.bz2 Now relogin via ssh and see if your problem still occurs. Good luck, and let us know how it goes. Andrew. -- 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/SSH-SCREEN-REATTACH-bug-tp22034385p22290354.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: [1.7] Editing in /etc
Perhaps I spoke to soon... I'm still having the issue, this time with a domain based user. I can't reproduce that, neither from a console window, nor from a mintty window. I've tried from both a console window and mintty and experience the same behaviour. I executed 'mkpasswd -l -c /etc/passwd' which again acted as expected, and the /etc/passwd file was created. I went to edit the file with 'vim -D /etc/passwd' to change the users' default group and vim again displayed the message about an error opening input. So this does not only occur in /etc? What happens if you start vim without the -D flag? This only occurs for any file in /etc. For simplicity, I tried: $ cd /etc $ echo Some text test.txt $ cat test.txt Some text $ vim text.txt and all I get is a screen with nothing but test.txt in the lower left hand corner. Looking in /dev I have: The content of /dev shouldn't matter, in theory. $ ls -ltr /proc/self/fd/0 lrwxrwxrwx 1 csutclif Users 0 Nov 30 2006 /proc/self/fd/0 - /dev/tty0 however, there is no /dev/tty0. Should there be? If so, how do I create it? http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices Ah, so the permissions on tty0 look correct: $ ls -l /dev/tty0 crw-rw-rw- 1 csutclif Users 136, 0 Nov 30 2006 /dev/tty0 I'm at a loss here, could anybody hazard an idea as to what could be happening, or how I could further debug the issue? Maybe something in /etc is making problems but I can't imagine what that is. This is a typical case where you just have to debug this. Strace might reveal a problem here. Or maybe it's a BLODA problem. How do I capture the strace output to a file? I tried 'strace vim /etc/passwd strace.out' but vim complained about stdout being redirected. Thanx! 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/
RE: [ANNOUNCEMENT] End-of-life/Updated: gcc-3.4.4-999
The new package for gcc-g++ is significantly bigger than the old. 3028397 2006-12-18 08:18:47 gcc-g++-3.4.4-3.tar.bz2 8016063 2009-03-02 10:23:49 gcc-g++-3.4.4-999.tar.bz2 Is this to be expected? - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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] Editing in /etc
Chris Sutcliffe wrote: Perhaps I spoke to soon... I'm still having the issue, this time with a domain based user. I can't reproduce that, neither from a console window, nor from a mintty window. I've tried from both a console window and mintty and experience the same behaviour. I executed 'mkpasswd -l -c /etc/passwd' which again acted as expected, and the /etc/passwd file was created. I went to edit the file with 'vim -D /etc/passwd' to change the users' default group and vim again displayed the message about an error opening input. So this does not only occur in /etc? What happens if you start vim without the -D flag? This only occurs for any file in /etc. For simplicity, I tried: $ cd /etc $ echo Some text test.txt $ cat test.txt Some text $ vim text.txt and all I get is a screen with nothing but test.txt in the lower left hand corner. Looking in /dev I have: The content of /dev shouldn't matter, in theory. $ ls -ltr /proc/self/fd/0 lrwxrwxrwx 1 csutclif Users 0 Nov 30 2006 /proc/self/fd/0 - /dev/tty0 however, there is no /dev/tty0. Should there be? If so, how do I create it? http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices Ah, so the permissions on tty0 look correct: $ ls -l /dev/tty0 crw-rw-rw- 1 csutclif Users 136, 0 Nov 30 2006 /dev/tty0 I'm at a loss here, could anybody hazard an idea as to what could be happening, or how I could further debug the issue? Maybe something in /etc is making problems but I can't imagine what that is. This is a typical case where you just have to debug this. Strace might reveal a problem here. Or maybe it's a BLODA problem. How do I capture the strace output to a file? I tried 'strace vim /etc/passwd strace.out' but vim complained about stdout being redirected. strace -o strace.out vim /etc/passwd -- 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/
job control: set CYGWIN=tty but ^Z doesn't work
What setup is need to get ^Z to suspend the current process? The CygWin manual Environment Variables section at http://cygwin.com/cygwin-ug-net/setup-env.html says: The CYGWIN variable is used ... [Y]ou can ... set it to tty (e.g. to support job control with ^Z etc...) using a syntax like this in the DOS shell, before launching bash. C:\ set CYGWIN=tty notitle glob I've added: set CYGWIN=tty to my Cygwin.bat file, but ^Z doesn't suspend a process. (E.g., running for (( i = 1 ; i '' 10 ; i = i + 1 )) ; do : ; done and pressing control-Z doesn't suspend the process running the loop. Thanks, Daniel -- 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: console scroll speed on Win XP
From: marchy...@hotmail.com To: cygwin@cygwin.com Subject: RE: console scroll speed on Win XP Date: Mon, 2 Mar 2009 09:20:24 -0500 From: jay.kr...@cornell.edu To: cygwin@cygwin.com; marchy...@hotmail.com; andy.ko...@gmail.com Subject: RE: console scroll speed on Win XP Date: Mon, 2 Mar 2009 11:34:08 + Andy Yep, the Windows console is slow alright, and I don't know of any way Huh? The windows console is fast, among the fastest I have ever used, BUT you must have the video driver for your specific card. I'm on a laptop and don't have a card, a Compaq Evo N610c with XP pro. I tried to update drivers from HP with no obvious effect. In any case mintty was a lot faster with no obvious drawbacks yet. I can appreciate there may be some issues but using the whole CPU while it scrolled by a rate just fast enough for reading seemed a bit odd. mintty is unreadably fast and probably some of cpu time goes to disk IO in my benchmark taskamanager test with cat :) IIRC, dir on a 4 Megahertz Z-80 computer was at least as fast. I would mention that getting the chipset support driver made a lot of difference- the DOS console is now usable but mintty is still faster and can't even max out the cpu now, although the regular cygwin window still does but now is too fast to read as it goes by. If you just have the generic VGA driver, it is slow, and other things are noticably too. _ Windows Live™: Life without walls. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009 -- 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] [1.7] Updated: {ncurses/libncurses-devel/ncurses-demo}-5.7-11; New: libncurses9-5.7-11
On Mar 1 17:28, Charles Wilson wrote: ncurses is a package that provides character and terminal handling libraries, including 'gui-like' panels and menus. It is often used instead of termcap. [[ compiled using gcc-3.4.4-3 ]] NOTE TO MAINTAINERS: You may need to add -ltinfo to LIBS when linking against ncurses. Is that really necessary? I'm wondering if the gain isn't overshadowed by the additional requirement at configure time. I don't see this lib on my Linux box either. And it might hurt configuring OOTB. 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/
Problem with perl in new release
I just installed the entire new release, with the 1.7 dll. Things are generally working well, with the exception of perl, which gives: caymen% perl /bin/perl.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Has anyone seen this before? Any suggestions? As an aside, this fixed the problems with xterm failing on Vista - now all my xterms start properly - thanks to whoever fixed that! David -- David Rudolph (781) 449-4511 (h) (617) 444-3680 (w) dcrudo...@ieee.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/
Re: job control: set CYGWIN=tty but ^Z doesn't work
2009/3/2 Daniel S. d...@smart.net: What setup is need to get ^Z to suspend the current process? The CygWin manual Environment Variables section at http://cygwin.com/cygwin-ug-net/setup-env.html says: The CYGWIN variable is used ... [Y]ou can ... set it to tty (e.g. to support job control with ^Z etc...) using a syntax like this in the DOS shell, before launching bash. You have to make sure that the CYGWIN variable is set before any Cygwin programs are run, because it is read when the Cygwin DLL is first loaded. Exiting all Cygwin processes before invoking cygwin.bat again should do the trick. Andy -- 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: job control: set CYGWIN=tty but ^Z doesn't work
On Mon, Mar 02, 2009 at 07:31:54PM +, Andy Koppe wrote: 2009/3/2 Daniel S.: What setup is need to get ^Z to suspend the current process? The CygWin manual Environment Variables section at http://cygwin.com/cygwin-ug-net/setup-env.html says: ?The CYGWIN variable is used ... [Y]ou can ... set it to tty (e.g. to support ?job control with ^Z etc...) using a syntax like this in the DOS shell, before ?launching bash. You have to make sure that the CYGWIN variable is set before any Cygwin programs are run, because it is read when the Cygwin DLL is first loaded. Exiting all Cygwin processes before invoking cygwin.bat again should do the trick. That shouldn't be necessary. The CYGWIN=tty is inherited by just one process. It isn't shared. for (( i = 1 ; i '' 10 ; i = i + 1 )) ; do : ; done Cygwin's CTRL-Z emulation isn't perfect. It may not work well in a scenario where you're in a tight loop in user space code which is what the above bash loop would be. 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/
FW: umount/mount issues
Subject: Re: umount/mount issues On Mar 2 12:04, Corinna Vinschen wrote: On Mar 1 22:21, Karl M wrote: Hi All... I also noticed in the Cygwin 1.7 user guide that just after example 3.11 the non-existant -s and -u options are referenced. Fixed. And more. While fixing the above it occured to me that the example cygdrive prefix used in the example is ... / *blush* Btw, I uploaded the fixed doc to http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html Please take a look. Thanks, Corinna -- Hi Corinna... In the Cygwin Mount Table description, there is a list of options, and managed is not listed. Managed is used in one of the later examples. When I get a change I will give it a thorough read. Thanks for your work on the documentation...I know it is a pain. ...Karl _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- 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/
1.5.25: rsync --delete and drive_letter: issue
cygwin rsync 3.0.4-1 --delete defaults to --delete-during but should be --delete-before also, i realize it would be a cygwin specific hack but has anyone entertained making a special case for cygwin rsync where it would recognize drive_letter: (instead of having to use /cygdrive/drive_letter)? all the folks in the world with one letter hostnames ;-) and cygwin are now cringing but thought i'ld throw it out there also i realize this other one should go to cygwin-xfree but thought i'ld run it by here since it might be simple, when i run xrdb -load ~/.Xdefaults i get no error, but then xrdb -query returns nothing, i even tried that -all flag which i'ld never seen before to no avail. p.s. this is my first cygwin mailing list post so hopefully i mostly got things right the problem reporting guidelines section in http://cygwin.com/problems.html doesn't state that the 1.5.x that you're supposed to put in the beginning of the Subject: is the main cygwin.dll version number - this might be obvious to non-newbies, but it wasn't real clear to me at first. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.25: rsync --delete and drive_letter: issue
On Mon, Mar 02, 2009 at 04:59:43PM -0500, Dat Head wrote: also, i realize it would be a cygwin specific hack but has anyone entertained making a special case for cygwin rsync where it would recognize drive_letter: (instead of having to use /cygdrive/drive_letter)? all the folks in the world with one letter hostnames ;-) and cygwin are now cringing but thought i'ld throw it out there You are missing one of the reasons for Cygwin - to avoid changing standard unix tools to deal with Windows p:\aths. So this is not something that we'd consider. the problem reporting guidelines section in http://cygwin.com/problems.html doesn't state that the 1.5.x that you're supposed to put in the beginning of the Subject: is the main cygwin.dll version number - this might be obvious to non-newbies, but it wasn't real clear to me at first. That's because it isn't required. We are temporarily putting [1.7] in the beginning of the subject while 1.7 is in beta but there is no requirement that 1.5.25 should be put in the beginning of everything else. You'll note that problems.html does talk about including cygcheck output as an attachment, however. The version of Cygwin is obvious there. 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: [ANNOUNCEMENT] [1.7] Updated: {ncurses/libncurses-devel/ncurses-demo}-5.7-11; New: libncurses9-5.7-11
Chris Sutcliffe wrote: NOTE TO MAINTAINERS: You may need to add -ltinfo to LIBS when linking against ncurses. Given that tgetent has moved to libtinfo, I've configured vim using: LIBS=-Wl,--enable-auto-import ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir='$(sbindir)' \ --localstatedir=/var \ --datadir='$(prefix)/share' \ --mandir='$(prefix)/share/man' \ --enable-multibyte \ --without-x \ --enable-gui=no \ --with-features=huge \ --with-tlib=tinfo Building vim completes without error. However, when I try and execute the new vim.exe, I get: Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault Checking vim.exe: $ cygcheck src/vim.exe C:\cygwin-1.7\usr\src\vim\vim7\src\vim.exe C:\cygwin-1.7\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin-1.7\bin\cygtinfo-9.dll Is there something I'm missing? I think you need to do this: --with-tlib=ncurses -ltinfo but hold off for now. I may respin ncurses without tinfo. -- Chuck -- 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: side effects after installing gcc-3.4.4.999
Akakima wrote: Why of course ?. You said in a previous post that the update would go without change in behaviour. Sorry, I guess it was only implied by my post: the behaviour of *Cygwin* applications hasn't changed. I can't make guarantees about what DOS or Windows will do because that's outside my control. (And I don't think it would make sense to avoid using Linux features in Cygwin just so that stuff will work from DOS!) I do not want to use gcc-3.exe. I have many .bat/.cmd files calling gcc and i do not want to modify them. I still want to be able to call gcc. Wouldn't a good solution be for your windows path to have an extra directory in it ahead of Cygwin's /bin directory, where you could put a windows shortcut to gcc-3.exe and call it gcc? That should work; by having this directory at the front of your PATH in DOS (but not in Cygwin) you could easily add overrides for the names of any Cygwin applications/symlinks that you wanted. and now if i type gcc, cmd finds gcc-3.exe and launch it. That didn't work when I tried it: C:\cygwin\etc\alternativesgcc Access is denied. Sorry, i dont know why. I assure you it works on my computer. The are many entries in the WIndows registry to support shortcuts. May be one of these entries is not ok on your machine. Yes, or it could just be a version difference. I use win2k on my main system. the two commands: gcc gcc --version ask for an enter. The command: gcc file.c does generate a.exe without asking for an enter. I dont know why but will do some more checks. Something very strange is happening! GCC doesn't read any input from stdin in any of those cases, so it's surprising that it behaves differently. Yes i want to use cmd.exe. This is ok i think. And i want to type gcc not ggc-3. (lots of .bat files with gcc.exe refs) It's your own choice, of course, but I'd consider modifying the batch files. It might be easier than you think to change them all in one go: find . -name '*.bat' | xargs sed -i -e 's/gcc.exe/gcc-3.exe/g' cmd.exe does understand links. I just reinstalled the update. Now, if i type (under cmd.exe): E:\cygwinE:\cygwin\etc\alternatives\gcc.lnk E:\cygwingcc-3: no input files --- waiting for an enter here. Enter does gives me the next line. E:\cygwin OK, hang on a moment, I know it might sound silly of me to ask but now I have to check: you aren't doing something unusual like running cmd.exe in a rxvt window are you? Or do you by any chance have CYGWIN=tty set in your environment variables? I wonder if it's really waiting for an enter, or if it's actually waiting for a full command line, and just the prompt hasn't been flushed to the screen yet. What happens if you type dir enter or some other command instead of just pressing enter on its own? In your earlier examples, where I said Cygwin doesn't read stdin anyway, that's still the case. But there is one difference that might be the reason here: when you run gcc file.c, gcc launches a number of subprocesses - preprocessor, compiler, assembler, linker. With the other two commands, it runs and exits without launching any other executables; I wonder if somehow that means that in one case all the output gets flushed and you see the prompt and know it's finished, in the other case the prompt gets lost in a buffer somewhere and you don't see it. Maybe launching subprocesses causes all the buffers to be flushed through in the first case. Now, i am not saying this is a bug in cygwin. Again, i just want to make someone aware of the fact this is not without change in behaviour. Sorry, yes, we're not always clear about this. Usage from DOS is a nice-to-have feature, but can't always be guaranteed to work the same as usage from within a Cygwin shell. When I said no change in behaviour, I was only thinking of within a Cygwin environment; my apologies for not being as clear as I could have been. For the moment, i undone the update. Later i will find something else. (Like copy gcc-3.exe gcc.exe). I would advise you consider my suggestion of having a renaming-and-overriding directory full of windows shortcuts at the head of your PATH. There are quite a lot of things in /bin that exist primarily as symlinks to the real application, gcc is just one among many. And if i want to use both gcc3 and gcc4, i will probably use a couples of bat files that will switch things around. That would work nicely with the directory-full-of-shortcuts approach, and basically you'd then have reimplemented in DOS the switching that I've done only within the Cygwin environment. Hey, I just tried that out to see if it works, and it does, but it also allows me to see the waits for enter problem occurring! It's definitely just the DOS prompt getting lost somehow; any command that you type before pressing enter does get executed when you do. Ah, look, it's not that the prompt is getting lost: it's just that GCC's output comes out after the
Re: [1.7] rebaseall doesn't solve the problem
Charles Wilson wrote: Corinna Vinschen wrote: Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. like perhaps a repeatable option Yep, this is exactly how I'm doing it. Patch will be posted shortly. Syntax looks like --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] e.g. --pe-dll-characteristics=0x0400|0x0100 --pe-dll-characteristics=1+128+1024,noseh,nobind --pe-dll-characteristics noseh:nobind:tsaware ... etc ... 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/
Re: [ANNOUNCEMENT] [1.7] Updated: {ncurses/libncurses-devel/ncurses-demo}-5.7-11; New: libncurses9-5.7-11
Corinna Vinschen wrote: NOTE TO MAINTAINERS: You may need to add -ltinfo to LIBS when linking against ncurses. Is that really necessary? I'm wondering if the gain isn't overshadowed by the additional requirement at configure time. I don't see this lib on my Linux box either. And it might hurt configuring OOTB. My idea was that it would make things easier on 1.7 down the road, when we have both ncurses and ncursesw, but only the one tinfo. For a survey of linux to make sense, you have to exclude those which ship only 5.6 and older -- which is quite a few; there was no tinfo option then. However, in my survey I find only one distro -- PLD -- that splits tinfo into a separate library, yet (almost) all of them ship both narrow and wide versions of ncurses. And PLD had to modify their vim configury to use --with-tlib='ncurses -ltinfo'. Both points reinforce your argument. Now, I would just say: Well, maintainers ought to use the handy new ncurses9-config script, or even the new pkginfo, which are now supplied with ncurses5.7. But I can't say that, because they're borked. They are apparently ELF-only, as they do not list the dependent libraries. That is, for win32, the ncurses++.pc file ought to list '-lncurses++ -lpanel -lform -lmenu -lncurses' (and maybe also -ltinfo, depending on the configuration), not just '-lncurses++ -lncurses'. Stay tuned for 5.7-3/5.7-12. Sigh. -- Chuck -- 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
Dave Korn wrote: Yep, this is exactly how I'm doing it. Patch will be posted shortly. Syntax looks like --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] e.g. --pe-dll-characteristics=0x0400|0x0100 --pe-dll-characteristics=1+128+1024,noseh,nobind --pe-dll-characteristics noseh:nobind:tsaware Nice. Where is the parsing done? I'm thinking of bringing in getopt_long support into rebase and peflags (which is available for both cygwin and mingw builds, just not MSVC. I don't think the rebase package cares about that). Anyway, if you've implemented that option parsing using just a small bit of magic over top of getopt_long, I'll just borrow it (both packages are GPL) and try to keep the interfaces for ld --pe-dll-characteristics peflags --dll-characteristics sorta similar (with maybe some nice short synonyms for the common peflags actions). OTOH, if it relies on a bunch of pre-existing ld/* glue, then... -- Chuck -- 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/
jasper package (jpeg-2000)
I can not find the jasper development package with setup.exe which should contain the c header files, etc. I could only find what appears to be the jasper 1.) utility programs and 2.) the runtime library i.e., jasper-1.900.1-1.tar.bz2 and libjasper1-1.900.1-1.tar.bz2 Can someone please give me the name of the jasper developement package, as I can't seem to find it with a name like jasper anywhere. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] End-of-life/Updated: gcc-3.4.4-999
Buchbinder, Barry (NIH/NIAID) [E] wrote: The new package for gcc-g++ is significantly bigger than the old. 3028397 2006-12-18 08:18:47 gcc-g++-3.4.4-3.tar.bz2 8016063 2009-03-02 10:23:49 gcc-g++-3.4.4-999.tar.bz2 Err.. no. Hold on and I'll find out why. Wonder if I forgot to strip something. 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/
Re: [1.7] rebaseall doesn't solve the problem
Charles Wilson wrote:
Dave Korn wrote:
Yep, this is exactly how I'm doing it. Patch will be posted shortly.
Syntax looks like
--pe-dll-characteristics=name|integer[(+|,:)name|integer[...]]
e.g.
--pe-dll-characteristics=0x0400|0x0100
--pe-dll-characteristics=1+128+1024,noseh,nobind
--pe-dll-characteristics noseh:nobind:tsaware
Nice. Where is the parsing done?
I added a variant of pe.em#set_pe_name() that can understand those sorts of
arguments, and a field in the definfo struct that allows to supply a list of
the abbreviated names and their corresponding values, so the mechanism is
nicely reusable.
Anyway, if you've implemented that option parsing using just a small bit
of magic over top of getopt_long, I'll just borrow it (both packages are
GPL) and try to keep the interfaces for
ld --pe-dll-characteristics
peflags --dll-characteristics
sorta similar
Yep, that would obviously be A Good Thing (TM).
(with maybe some nice short synonyms for the common peflags actions).
The mechanism is ready and waiting for you, just add the data tables!
OTOH, if it relies on a bunch of pre-existing ld/* glue, then...
Nope, should be easy to cut out the relevant bits, discarding ld-isms, and
paste the remainder into your code. Copy of WIP attached for your
convenience; I've got to add doco and testcases before I can submit it, but
the parsing stuff is ready to fly and I'd appreciate any extra testing it gets
:)
cheers,
DaveK
? x.s
Index: include/coff/pe.h
===
RCS file: /cvs/src/src/include/coff/pe.h,v
retrieving revision 1.18
diff -p -u -r1.18 pe.h
--- include/coff/pe.h 4 Nov 2007 23:49:08 - 1.18
+++ include/coff/pe.h 3 Mar 2009 01:55:05 -
@@ -38,6 +38,17 @@
#define IMAGE_FILE_UP_SYSTEM_ONLY0x4000
#define IMAGE_FILE_BYTES_REVERSED_HI 0x8000
+/* DllCharacteristics flag bits. The inconsistent naming may seem
+ odd, but that is how they are defined in the PE specification. */
+#define IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE 0x0040
+#define IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY 0x0080
+#define IMAGE_DLL_CHARACTERISTICS_NX_COMPAT 0x0100
+#define IMAGE_DLLCHARACTERISTICS_NO_ISOLATION 0x0200
+#define IMAGE_DLLCHARACTERISTICS_NO_SEH 0x0400
+#define IMAGE_DLLCHARACTERISTICS_NO_BIND0x0800
+#define IMAGE_DLLCHARACTERISTICS_WDM_DRIVER 0x2000
+#define IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE 0x8000
+
/* Additional flags to be set for section headers to allow the NT loader to
read and write to the section data (to replace the addresses of data in
dlls for one thing); also to execute the section in .text's case. */
Index: ld/NEWS
===
RCS file: /cvs/src/src/ld/NEWS,v
retrieving revision 1.97
diff -p -u -r1.97 NEWS
--- ld/NEWS 18 Feb 2009 18:23:07 - 1.97
+++ ld/NEWS 3 Mar 2009 01:55:06 -
@@ -1,5 +1,9 @@
-*- text -*-
+* A new command-line flag '--pe-dll-characteristics' allows PE targets
+ to set the value of the PE file header's DllCharacteristics field,
+ using a flexible combination of numeric and symbolic names.
+
* PE targets no longer make use of the long section names PE extension to
the COFF format when generating executable images, by default. The old
(slightly non-conformant) behaviour can still be invoked by using the
Index: ld/emultempl/pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.145
diff -p -u -r1.145 pe.em
--- ld/emultempl/pe.em 27 Feb 2009 19:01:56 - 1.145
+++ ld/emultempl/pe.em 3 Mar 2009 01:55:06 -
@@ -229,6 +229,8 @@ fragment EOF
(OPTION_USE_NUL_PREFIXED_IMPORT_TABLES
+ 1)
#define OPTION_DISABLE_LONG_SECTION_NAMES \
(OPTION_ENABLE_LONG_SECTION_NAMES + 1)
+#define OPTION_PE_DLL_CHARACTERISTICS \
+ (OPTION_DISABLE_LONG_SECTION_NAMES + 1)
static void
gld${EMULATION_NAME}_add_options
@@ -290,6 +292,7 @@ gld${EMULATION_NAME}_add_options
{large-address-aware, no_argument, NULL, OPTION_LARGE_ADDRESS_AWARE},
{enable-long-section-names, no_argument, NULL,
OPTION_ENABLE_LONG_SECTION_NAMES},
{disable-long-section-names, no_argument, NULL,
OPTION_DISABLE_LONG_SECTION_NAMES},
+{pe-dll-characteristics, required_argument, NULL,
OPTION_PE_DLL_CHARACTERISTICS},
{NULL, no_argument, NULL, 0}
};
@@ -303,14 +306,47 @@ gld${EMULATION_NAME}_add_options
typedef struct
{
+ const char *name;
+ int len;
+ int value;
+} definfoflag;
+
+#define C(name) { #name, sizeof(#name) - 1, name }
+#define CF(name,flag) { #name, sizeof(#name) - 1, flag }
+static const definfoflag dllchrctnames[] =
+{
+ /*
Re: side effects after installing gcc-3.4.4.999
Dave Korn wrote: Windows will do because that's outside my control. (And I don't think it would make sense to avoid using Linux features in Cygwin just so that stuff will work from DOS!) I agree 99.99 % with you. :-). the 0.01 is about would you please not totally forget that cygwin is running on a Win32 platform. (no offense here, no joke, no disrecpect, ...) Technicaly it's not DOS, but the WinXP command prompt window. This windows behave like a DOS console but this is not a DOS application. This a win32 application using a rather feature limited subset of the winapi. (sorry if you already know this). Wouldn't a good solution be for your windows path to have an extra directory in it ahead of Cygwin's /bin directory, where you could put a windows shortcut to gcc-3.exe and call it gcc? That should work; by having this directory at the front of your PATH in DOS (but not in Cygwin) you could easily add overrides for the names of any Cygwin applications/symlinks that you wanted. Yes, it is a good idea. I already have a set of batch files that fix the PATH an other environments variables depending with what compiler i am working with. setcygwin.cmd for Cywin setmingw.cmd for MingW etc... This works quite well. Each new instance of the cmd.exe can have its own set of variables. Yes, or it could just be a version difference. I use win2k on my main system. I use WinXP Pro, SP2. Something very strange is happening! GCC doesn't read any input from stdin in any of those cases, so it's surprising that it behaves differently. Ah! It might be easier than you think to change them all in one go: find . -name '*.bat' | xargs sed -i -e 's/gcc.exe/gcc-3.exe/g' Thanks for the tip. OK, hang on a moment, I know it might sound silly of me to ask but now I have to check: you aren't doing something unusual like running cmd.exe in a rxvt window are you? Or do you by any chance have CYGWIN=tty set in your No. No. environment variables? I wonder if it's really waiting for an enter, or if it's actually waiting for a full command line, and just the prompt hasn't been flushed to the screen yet. What happens if you type dir enter or some other command instead of just pressing enter on its own? Now you got it. After doing some other test that's what i found. Effectively if you type a command there, that command is executed. So this is cmd.exe waiting for input (but the prompt has not been displayed or has been erased) In your earlier examples, where I said Cygwin doesn't read stdin anyway, that's still the case. But there is one difference that might be the reason here: when you run gcc file.c, gcc launches a number of subprocesses - preprocessor, compiler, assembler, linker. With the other two commands, it runs and exits without launching any other executables; I wonder if somehow that means that in one case all the output gets flushed and you see the prompt and know it's finished, in the other case the prompt gets lost in a buffer somewhere and you don't see it. Maybe launching subprocesses causes all the buffers to be flushed through in the first case. I dont know and i dont know how to test that. I made some other tests. I created the shortcut from the explorer. May be cygwin was creating the shortcut in a way that caused that behaviour, or may be it was because cygwin does not use \r (just \n). Same results. I also tried to create a shortcut to mingw gcc.exe (which emits \r\n). Same results. And i tried with a small program who does only write to stderr, and compiled it with VisualC++ v6.0 : Same results. Conclusion: this is related to the way cmd.exe process and run the target of the shortcut. Shortcuts are normally ran from the explorer. I guess bash is a little more intelligent. I would advise you consider my suggestion of having a renaming-and-overriding directory full of windows shortcuts at the head of your PATH. There are quite a lot of things in /bin that exist primarily as symlinks to the real application, gcc is just one among many. That would be perfect, because with all the good settings, the change would be completly transparent. If cmd.exe was not the culprit. As illustrated. Hey, I just tried that out to see if it works, and it does, but it also allows me to see the waits for enter problem occurring! It's definitely just the DOS prompt getting lost somehow; any command that you type before pressing enter does get executed when you do. Ah, look, it's not that the prompt is getting lost: it's just that GCC's output comes out after the prompt for some reason. See the example below: Is that how it's happening for you? Yes!. Exactly. I tried many variants to launch the shortcut. Each time, the results are the same. Thanks for taking the time to verify this. If i find a solution i will report it here. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports:
Re: side effects after installing gcc-3.4.4.999
Dave Korn wrote: Windows will do because that's outside my control. (And I don't think it would make sense to avoid using Linux features in Cygwin just so that stuff will work from DOS!) I agree 99.99 % with you. :-). the 0.01 is about would you please not totally forget that cygwin is running on a Win32 platform. (no offense here, no joke, no disrecpect, ...) Technicaly it's not DOS, but the WinXP command prompt window. This windows behave like a DOS console but this is not a DOS application. This a win32 application using a rather feature limited subset of the winapi. (sorry if you already know this). Wouldn't a good solution be for your windows path to have an extra directory in it ahead of Cygwin's /bin directory, where you could put a windows shortcut to gcc-3.exe and call it gcc? That should work; by having this directory at the front of your PATH in DOS (but not in Cygwin) you could easily add overrides for the names of any Cygwin applications/symlinks that you wanted. Yes, it is a good idea. I already have a set of batch files that fix the PATH an other environments variables depending with what compiler i am working with. setcygwin.cmd for Cywin setmingw.cmd for MingW etc... This works quite well. Each new instance of the cmd.exe can have its own set of variables. Yes, or it could just be a version difference. I use win2k on my main system. I use WinXP Pro, SP2. Something very strange is happening! GCC doesn't read any input from stdin in any of those cases, so it's surprising that it behaves differently. Ah! It might be easier than you think to change them all in one go: find . -name '*.bat' | xargs sed -i -e 's/gcc.exe/gcc-3.exe/g' Thanks for the tip. OK, hang on a moment, I know it might sound silly of me to ask but now I have to check: you aren't doing something unusual like running cmd.exe in a rxvt window are you? Or do you by any chance have CYGWIN=tty set in your No. No. environment variables? I wonder if it's really waiting for an enter, or if it's actually waiting for a full command line, and just the prompt hasn't been flushed to the screen yet. What happens if you type dir enter or some other command instead of just pressing enter on its own? Now you got it. After doing some other test that's what i found. Effectively if you type a command there, that command is executed. So this is cmd.exe waiting for input (but the prompt has not been displayed or has been erased) In your earlier examples, where I said Cygwin doesn't read stdin anyway, that's still the case. But there is one difference that might be the reason here: when you run gcc file.c, gcc launches a number of subprocesses - preprocessor, compiler, assembler, linker. With the other two commands, it runs and exits without launching any other executables; I wonder if somehow that means that in one case all the output gets flushed and you see the prompt and know it's finished, in the other case the prompt gets lost in a buffer somewhere and you don't see it. Maybe launching subprocesses causes all the buffers to be flushed through in the first case. I dont know and i dont know how to test that. I also made some other tests. I created the shortcut from the explorer. May be cygwin was creating the shortcut in a way that caused that behaviour, or may be it was because cygwin does not use \r (just \n). Same results. I also tried to create a shortcut to mingw gcc.exe (which emits \r\n). Same results. And i tried with a small program who does only write to stderr, and compiled it with VisualC++ v6.0 : Same results. Conclusion: this is related to the way cmd.exe process and run the target of the shortcut. Shortcuts are normally ran from the explorer. I guess bash is a little more intelligent. I would advise you consider my suggestion of having a renaming-and-overriding directory full of windows shortcuts at the head of your PATH. There are quite a lot of things in /bin that exist primarily as symlinks to the real application, gcc is just one among many. That would be perfect, because with all the good settings, the change would be completly transparent. If cmd.exe was not the culprit. As illustrated. Hey, I just tried that out to see if it works, and it does, but it also allows me to see the waits for enter problem occurring! It's definitely just the DOS prompt getting lost somehow; any command that you type before pressing enter does get executed when you do. Ah, look, it's not that the prompt is getting lost: it's just that GCC's output comes out after the prompt for some reason. See the example below: Is that how it's happening for you? Yes!. Exactly. I tried many variants to launch the shortcut. Each time, the results are the same. Thanks for taking the time to verify this. If i find a solution i will report it here. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation:
pdftk and apropos - general questions
Hi, Thanks for the help with mintty earlier. I've had a persistent problem getting apropos to work as it never finds anything appropriate. Is there something I need to do to make this work? The immediate need was trying to find pdf tools. Browsing the installs, it looks like pdftk will probably do what I need, along with other utilities I have. Are there additional pdf tools internal or external to cygwin people have found useful? Basically on this new computer I've managed to do without Flash so far and I'd like to try to avoid installing any Adobe reader stuff. Unfortunately, many government agencies seem to think that scanned pdf files are as good as text ( notably FDA and FCC, IRS PDF's so far seem to convert to text but formatting is awful). I noticed that pdftk has features for filling in pdf forms. Has anyone actually got examples of using this with scripts of other stuff ( let's say I wanted to fill out PDF tax forms from a script, IIRC most of these are pdf forms ). Thanks Mike Marchywka _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- 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: side effects after installing gcc-3.4.4.999
Akakima wrote: I agree 99.99 % with you. :-). the 0.01 is about would you please not totally forget that cygwin is running on a Win32 platform. (no offense here, no joke, no disrecpect, ...) Absolutely, no offence taken, and I'm sorry if my earlier post seemed that I had done so. We of course don't want to forget that we're running on win32, and I don't want to do anything to needlessly break using Cygwin apps directly from win32, but I even more don't want to do anything to hold back the completeness and improvement of the POSIX side of things for the sake of the win32 side. Fair? :-) Technicaly it's not DOS, but the WinXP command prompt window. This windows behave like a DOS console but this is not a DOS application. This a win32 application using a rather feature limited subset of the winapi. (sorry if you already know this). Yes; what I meant by that distinction was that you're running the cmd.exe shell, which is the modern-day equivalent of DOS, inside a text-mode console window, as opposed to running a Cygwin shell (which can be run in a text-mode console window *or* in a GUI terminal like rxvt). The point is about the environment from which applications are launched, not the console used. Yes, it is a good idea. I already have a set of batch files that fix the PATH an other environments variables depending with what compiler i am working with. setcygwin.cmd for Cywin setmingw.cmd for MingW etc... This works quite well. Each new instance of the cmd.exe can have its own set of variables. Writing yourself a few simple scripts/batch files like this is definitely the way to make your life easier when trying to manage these potentially-conflicting environments. somewhere and you don't see it. Maybe launching subprocesses causes all the buffers to be flushed through in the first case. I dont know and i dont know how to test that. Sorry, I was just thinking out loud, that wasn't meant to be useful as an idea for testing! Conclusion: this is related to the way cmd.exe process and run the target of the shortcut. Shortcuts are normally ran from the explorer. I guess bash is a little more intelligent. That would be perfect, because with all the good settings, the change would be completly transparent. If cmd.exe was not the culprit. As illustrated. Is that how it's happening for you? Yes!. Exactly. I tried many variants to launch the shortcut. Each time, the results are the same. Thanks for taking the time to verify this. If i find a solution i will report it here. That would be good, thank you. It may be that there's nothing you can do. Then again, it may be a sign that we're missing a flush somewhere in the Cygwin DLL. Are you trying with 1.5 or 1.7? If you haven't tried 1.7 yet, you can give it a go; follow the instructions in the most recent announcement posting, and it's simple to try out a parallel installation that doesn't mess with your current 1.5 setup. In the meantime, I suggest that you don't worry too much about it. The compiler works, every command you enter is executed, and the only thing wrong is that the prompt goes missing somehow. That hopefully won't break any of your scripts or batch files. 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/
Re: pdftk and apropos - general questions
On 03/02/2009, Mike Marchywka wrote: I've had a persistent problem getting apropos to work as it never finds anything appropriate. Is there something I need to do to make this work? man apropos man whatis -- 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: pdftk and apropos - general questions
Date: Mon, 2 Mar 2009 22:38:42 -0500 From: reply-to-list-only...@cygwin.com To: cygwin@cygwin.com Subject: Re: pdftk and apropos - general questions On 03/02/2009, Mike Marchywka wrote: I've had a persistent problem getting apropos to work as it never finds anything appropriate. Is there something I need to do to make this work? man apropos man whatis lol, so if I just do /usr/sbin/makewhatis it should build the files but I should wait until I have everything in I want indexed. I guess it never occurred to me to man the help things but man man works too -- 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/ _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme -- 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 Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: Charles Wilson wrote: Corinna Vinschen wrote: Btw., I just noticed that the Visual C++ Linker sets the TS-aware flag by default, see http://msdn.microsoft.com/en-us/library/01cfys9z.aspx It would probably be very helpful in the long run if ld had some generic option to set any of the Windows-specific header flags at build time. like perhaps a repeatable option Yep, this is exactly how I'm doing it. Patch will be posted shortly. Syntax looks like --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] e.g. --pe-dll-characteristics=0x0400|0x0100 --pe-dll-characteristics=1+128+1024,noseh,nobind --pe-dll-characteristics noseh:nobind:tsaware I thought we'd established that these aren't just dll characteristics. 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: [1.7] rebaseall doesn't solve the problem
Christopher Faylor wrote: On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] I thought we'd established that these aren't just dll characteristics. Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff extension header), so it's canonical, regardless if it also applies to executables. 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/
Re: [1.7] rebaseall doesn't solve the problem
On Tue, Mar 03, 2009 at 05:00:28AM +, Dave Korn wrote: Christopher Faylor wrote: On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] I thought we'd established that these aren't just dll characteristics. Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff extension header), so it's canonical, regardless if it also applies to executables. Yes, I am aware of this. Regardless, I don't think a publicly-exposed interface should be unclear like this. 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/
Best way to install openssh
It has been quite a while since I've updated any of the packages on my XP system. I want to start sshd on the XP box so that I can access it from my Solaris 10 box in order to modify my crontab file. What is the best way to get and install oppenssh? Thanks. MB -- e-mail: vid...@vidiot.com/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ / \ HTML Email Dakota: Loving K9 companion [Jan 1993 - Sep 22, 2008] -- 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: Best way to install openssh
Mike Brown wrote: What is the best way to get and install oppenssh? It's part of the cygwin distro, so use setup.exe. Look for OpenSSH. After installing it, read the docs in /usr/share/doc/Cygwin/openssh.README and in /usr/share/doc/openssh/, then use the ssh-host-config script to set it all up. 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/
Re: [1.7] rebaseall doesn't solve the problem
Christopher Faylor wrote: On Tue, Mar 03, 2009 at 05:00:28AM +, Dave Korn wrote: Christopher Faylor wrote: On Mon, Mar 02, 2009 at 10:00:30PM +, Dave Korn wrote: --pe-dll-characteristics=name|integer[(+|,:)name|integer[...]] I thought we'd established that these aren't just dll characteristics. Well, it's the name of the field in the PE IMAGE_OPTIONAL_HEADER (coff extension header), so it's canonical, regardless if it also applies to executables. Yes, I am aware of this. Regardless, I don't think a publicly-exposed interface should be unclear like this. We can discuss this in depth on the binutils list when I submit the patch, there's not much point in having a long OT thread here. Let's see what the other PE stakeholders feel. 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/
rsync hanging on Access MDB file
Several months ago set up a remote backup for a client. The remote server, running OpenSuSe 11, runs rsync over ssh to two remote servers in the same location. One server is Linux (a variant of CentOS 4.6), while the other is a Windows 2008 server box. Until last week, everything was working well; however, now I am seeing this error in the log when backing up from the Windows server: rsync: connection unexpectedly closed (449058 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(635) [receiver=3.0.2] rsync: connection unexpectedly closed (237 bytes received so far) [generator] rsync error: unexplained error (code 255) at io.c(635) [generator=3.0.2] The error occurs each time on the same Access database file (part of the application suite the server was installed for). I have tested various scenarios - I deleted the file on the backup server and tried to run the rsync process, with the same result; I then copied the file to a temporary directory on the source server and backed up just that directory - which worked. From that I thought it might be either a permissions issue or an oddity in the original file. I therefore copied the file back from the temp directory and tried again - same result. I checked file permissions, which were fine, with the backup user having sufficient rights to the folder tree. rsync on the Cygwin side is version 3.0.4; on OpenSuSE, version 3.0.2. I searched for rsync problems with MDB files, but came up with nothing. If anyone has an idea of why this is happening and how I can fix it, I'd be grateful. Thanks, -- Des Dougan, Principal Dougan Consulting Group Inc. Office: 604-628-5434 Cell: 604-866-2848 Email: des at DouganConsulting dot com www.DouganConsulting.com Peace of Mind, One Computer at a Time. -- 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/
R: jasper package (jpeg-2000)
--- Mar 3/3/09, wynfi...@gmail.com ha scritto: Da: wynfi...@gmail.com Oggetto: jasper package (jpeg-2000) A: cygwin@cygwin.com Data: Martedì 3 marzo 2009, 03:29 I can not find the jasper development package with setup.exe which should contain the c header files, etc. I could only find what appears to be the jasper 1.) utility programs and 2.) the runtime library i.e., jasper-1.900.1-1.tar.bz2 and libjasper1-1.900.1-1.tar.bz2 Can someone please give me the name of the jasper developement package, as I can't seem to find it with a name like jasper anywhere. Thanks. Try here http://cygwin.com/packages/ I guess libjasper-develJPEG 2000 library - (development) Marco Passa a Yahoo! Mail. La webmail che ti offre GRATIS spazio illimitato, antispam e messenger integrato. http://it.mail.yahoo.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/
