Re: Cygwin 1.7 release (was Re: The library or libraries will be delivered[...])
Chris, how would you and the other MinGW developers feel about moving mingw and w32api somewhere else? Just to be clear: By somewhere else I meant into their own repositories, not away from sourceware. I'll bring it up with the other MinGW developers, but from my point of view, I'm more than happy to do whatever you need me to do. The general consensus within the MinGW development team is that there is no objection to moving the w32api or mingw-runtime repositories. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org
Re: Cygwin 1.7 release (was Re: The library or libraries will be delivered[...])
On Fri, Jun 05, 2009 at 06:19:48PM -0400, Chris Sutcliffe wrote: Chris, how would you and the other MinGW developers feel about moving mingw and w32api somewhere else? Just to be clear: By somewhere else I meant into their own repositories, not away from sourceware. I'll bring it up with the other MinGW developers, but from my point of view, I'm more than happy to do whatever you need me to do. The general consensus within the MinGW development team is that there is no objection to moving the w32api or mingw-runtime repositories. Thanks for the feedback. cgf
Re: Windows 7 RC1 and Cygwin 1.7
On 15/05/2009 15:13, Jim Reisert AD1C wrote: I have installed Windows 7 RC1 (64-bit) as well as Cygwin 1.7, including the Xorg stuff in the Cygwin setup-1.7.exe file Same here. I have also noticed the following issues: 1) In multiwindow mode, all X programs are considered as one wrt taskbar buttons. Nothing really new there, but it's more noticeable now that the default is Always combine, hide labels. When combined, the icon shown is that of the first program launched, which is obviously inaccurate if several different X programs are running. If a windowed X server is launched, it shows as one window with the X icon (as expected), which will be grouped together with X programs running multiwindow on a different DISPLAY. Pinning that X icon to the taskbar has the same effect. It would be preferable to force ungrouping (or grouping by program in multiwindow, if possible), but if that's not possible, the X icon should represent the group no matter which program launched first. 2) It would be nice to port the tray icon menu to the new Jump List. 3) With Aero in multiwindow, fbpanel (in Ports) has a large border around the panel. IIRC there was a slight border in XP, but it's much larger and more noticeable with Aero. 4) In multiwindow, if two programs overlap, then Aero Peek will show the correct shape for each window but the contents of one window superimposed on the other in their stacking order. Anyone else testing 7RC1? Yaakov Cygwin/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/
src/winsup/cygwin winbase.h ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: da...@sourceware.org2009-06-05 13:53:02 Modified files: winsup/cygwin : winbase.h ChangeLog Log message: * winbase.h (ilockexch): Fix asm constraints. (ilockcmpexch): Likewise. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/winbase.h.diff?cvsroot=srcr1=1.14r2=1.15 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4507r2=1.4508
Re: [PATCH?] Separate pthread patches, #2 take 2.
Corinna Vinschen wrote:
On Jun 4 02:52, Dave Korn wrote:
Dave Korn wrote:
Dave Korn wrote:
The attached patch implements ilockexch and ilockcmpexch, using the
inline
asm definition from __arch_compare_and_exchange_val_32_acq in
glibc-2.10.1/sysdeps/i386/i486/bits/atomic.h, trivially expanded inline
rather
than in its original preprocessor macro form.
It generates incorrect code.
This much looks like it's probably a compiler bug.
Let's see whether anyone else agrees:
http://gcc.gnu.org/ml/gcc/2009-06/msg00053.html
When you checked in this change, I'll create a 1.7.0-49 test release.
This is the final version I committed. It is the glibc version, with the
addition of the memory clobber, which that discussion revealed was absolutely
required, and the use of a register asm var to feed the inline asm, which is
in accordance with documented practice in the gcc manual. (This now leaves
only one difference between the glibc version and the version I posted, which
is the use of a +a write-only output constraint paired with a numeric 0
matching input constraint in glibc's version compared with a single output
operand using the read-write constraing =a in my version. These should in
fact be exactly identical in terms of what they indicate to reload, in any
case.)
I have also manually inspected the generated assembly from thread.cc and
shared.cc in a cygwin DLL build and verified that it is correct and efficient,
and have installed the resulting DLL and retested all Thomas Stalder's
testcases and the previously intermittently failing pthread7-rope testcase
from libstdc++ testsuite. Committed with this ChangeLog:
winsup/cygwin/ChangeLog
* winbase.h (ilockexch): Fix asm constraints.
(ilockcmpexch): Likewise.
Libstdc++ plan after the weekend. Cheers all!
cheers,
DaveK
? winsup/cygwin/cygwin-cxx.h
? winsup/cygwin/mutex
Index: winsup/cygwin/winbase.h
===
RCS file: /cvs/src/src/winsup/cygwin/winbase.h,v
retrieving revision 1.14
diff -p -u -r1.14 winbase.h
--- winsup/cygwin/winbase.h 12 Jul 2008 18:09:17 - 1.14
+++ winsup/cygwin/winbase.h 5 Jun 2009 13:05:08 -
@@ -38,22 +38,31 @@ ilockdecr (volatile long *m)
extern __inline__ long
ilockexch (volatile long *t, long v)
{
- register int __res;
- __asm__ __volatile__ (\n\
-1: lock cmpxchgl %3,(%1)\n\
- jne 1b\n\
- : =a (__res), =q (t): 1 (t), q (v), 0 (*t): cc);
- return __res;
+ return
+ ({
+register __typeof (*t) ret __asm (%eax);
+__asm __volatile (\n
+ 1: lock cmpxchgl %2, %1\n
+ jne 1b\n
+ : =a (ret), =m (*t)
+ : r (v), m (*t), 0 (*t)
+ : memory);
+ret;
+ });
}
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
- register int __res;
- __asm__ __volatile__ (\n\
- lock cmpxchgl %3,(%1)\n\
- : =a (__res), =q (t) : 1 (t), q (v), 0 (c): cc);
- return __res;
+ return
+ ({
+register __typeof (*t) ret __asm (%eax);
+__asm __volatile (lock cmpxchgl %2, %1
+ : =a (ret), =m (*t)
+ : r (v), m (*t), 0 (c)
+ : memory);
+ret;
+ });
}
#undef InterlockedIncrement
Re: [PATCH?] Separate pthread patches, #2 take 2.
On Jun 5 15:04, Dave Korn wrote: Corinna Vinschen wrote: On Jun 4 02:52, Dave Korn wrote: Dave Korn wrote: Dave Korn wrote: The attached patch implements ilockexch and ilockcmpexch, using the inline asm definition from __arch_compare_and_exchange_val_32_acq in glibc-2.10.1/sysdeps/i386/i486/bits/atomic.h, trivially expanded inline rather than in its original preprocessor macro form. It generates incorrect code. This much looks like it's probably a compiler bug. Let's see whether anyone else agrees: http://gcc.gnu.org/ml/gcc/2009-06/msg00053.html When you checked in this change, I'll create a 1.7.0-49 test release. This is the final version I committed. It is the glibc version, with the addition of the memory clobber, which that discussion revealed was absolutely required, and the use of a register asm var to feed the inline asm, which is in accordance with documented practice in the gcc manual. (This now leaves only one difference between the glibc version and the version I posted, which is the use of a +a write-only output constraint paired with a numeric 0 matching input constraint in glibc's version compared with a single output operand using the read-write constraing =a in my version. These should in fact be exactly identical in terms of what they indicate to reload, in any case.) I have also manually inspected the generated assembly from thread.cc and shared.cc in a cygwin DLL build and verified that it is correct and efficient, and have installed the resulting DLL and retested all Thomas Stalder's testcases and the previously intermittently failing pthread7-rope testcase from libstdc++ testsuite. Committed with this ChangeLog: Cool, thank you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH?] Separate pthread patches, #2 take 2.
On Fri, Jun 05, 2009 at 03:04:59PM +0100, Dave Korn wrote: winsup/cygwin/ChangeLog * winbase.h (ilockexch): Fix asm constraints. (ilockcmpexch): Likewise. Thanks for seeing this through. It was obviously a lot of work. cgf
Re: [PATCH?] Separate pthread patches, #2 take 2.
Christopher Faylor wrote: On Fri, Jun 05, 2009 at 03:04:59PM +0100, Dave Korn wrote: winsup/cygwin/ChangeLog * winbase.h (ilockexch): Fix asm constraints. (ilockcmpexch): Likewise. Thanks for seeing this through. It was obviously a lot of work. cgf I appreciate the need to be diligent when working so deep in the bowels of the fundaments, so no problem :) cheers, DaveK
Re: Re: Why bash failed to match this pattern?
But some bash does match the pattern: $bash --version GNU bash, version 3.2.33(1)-release (i386-redhat-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Maybe some settings affect bash's behaviour. PRC -- 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: Re: Why bash failed to match this pattern?
On Fri, Jun 5, 2009 at 2:35 AM, Pan ruochen But some bash does match the pattern: It's possible that the behavior has changed between bash versions, but the behavior is not Cygwin-specific. 3.2.17 on OS X also suppresses metacharacters with quotation marks, and the documentation indicates that this is the expected behavior. See http://www.gnu.org/software/bash/manual/bashref.html#Conditional-Constructs Under [[...]], third paragraph: An additional binary operator, ‘=~’, is available [...] Any part of the pattern may be quoted to force it to be matched as a string. $bash --version GNU bash, version 3.2.33(1)-release (i386-redhat-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Maybe some settings affect bash's behaviour. PRC -- Mark J. Reed markjr...@gmail.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: Cygwin SSH Multiple Users
Hello, We reinstalled WINXP and CYGWIN with another dumps. But still not able to start the sshd service. Really frustrated as we followed exact steps given in most of the internet help pages. So whats going wrong , is there any way to find out what more is needed or so? Where can we have the sshd logs. One file we found is /var/log/sshd.log ...But its empty... Please suggest. Thanks, sac -Original Message- From: Holikar, Sachin (ext) Sent: Donnerstag, 4. Juni 2009 08:14 To: 'cygwin@cygwin.com' Subject: RE: Cygwin SSH Multiple Users Hello, Thanks for the info Corinna but ultimately we aint able to start the service somehow. And only way to start is to start with the user mac using /usr/sbin/sshd. But then no other user can connect via ssh to this machine. The work around we provided was copiying the ssh public keys of the user say admin and then connecting from remote machine using ssh -l mac winxp and then admin gets the ssh access as mac. But now the requirement is to be able to login as different users to this machine and we are stuck up. Really confused what went wrong. Any hint will be much appreciated. Thanks, sac -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Mittwoch, 3. Juni 2009 17:53 To: cygwin@cygwin.com Subject: Re: Cygwin SSH Multiple Users On Jun 3 11:11, Georg Nikodym wrote: Also, Win32 error 1062 doesn't tell anybody anything. Paste more of the session to provide some context. bash$ net helpmsg 1062 The service has not been started. 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/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin SSH Multiple Users
use command /usr/sbin/sshd to try start first And which cygwin version you use? 2009/6/5 Holikar, Sachin (ext) sachin.holikar@siemens.com: Hello, We reinstalled WINXP and CYGWIN with another dumps. But still not able to start the sshd service. Really frustrated as we followed exact steps given in most of the internet help pages. So whats going wrong , is there any way to find out what more is needed or so? Where can we have the sshd logs. One file we found is /var/log/sshd.log ...But its empty... Please suggest. Thanks, sac -Original Message- From: Holikar, Sachin (ext) Sent: Donnerstag, 4. Juni 2009 08:14 To: 'cygwin@cygwin.com' Subject: RE: Cygwin SSH Multiple Users Hello, Thanks for the info Corinna but ultimately we aint able to start the service somehow. And only way to start is to start with the user mac using /usr/sbin/sshd. But then no other user can connect via ssh to this machine. The work around we provided was copiying the ssh public keys of the user say admin and then connecting from remote machine using ssh -l mac winxp and then admin gets the ssh access as mac. But now the requirement is to be able to login as different users to this machine and we are stuck up. Really confused what went wrong. Any hint will be much appreciated. Thanks, sac -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Mittwoch, 3. Juni 2009 17:53 To: cygwin@cygwin.com Subject: Re: Cygwin SSH Multiple Users On Jun 3 11:11, Georg Nikodym wrote: Also, Win32 error 1062 doesn't tell anybody anything. Paste more of the session to provide some context. bash$ net helpmsg 1062 The service has not been started. 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/ -- 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/
Re: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
On Jun 4 19:49, Yaakov S wrote: On 04/06/2009 14:28, Yaakov (Cygwin/X) wrote: I'm having similar problems with Avast 4.8 Home Edition on Windows 7 RC x64 with cygwin-1.7. I never had a problem with this A/V on XP with 1.5 or 1.7. This continues even after rebaseall and peflagsall. I have yet to try removing Avast. OK, I've uninstalled Avast, disabled Windows Firewall and Defender, ran rebaseall and peflagsall (tried ASLR on and off), and I still the same errors. I can't even bootstrap cygport now, it's so bad. I can reproduce the unable to remap on W7RC by running `cygport automake1.11-1.11-10 compile'. The culprit in my case is always the same DLL, a run-time loaded perl DLL called Cwd.dll. Even after rebaseall, it still doesn't work because the Windows Loader tries to load the DLL into an entirely different address. When examining the memory layout of the parent, it stands out that Cwd.dll was already loaded into another address than the DLLs base address. The base addr of Cwd.dll is 0x6ee0, the end address would be 0x6ee08000. There's no other DLL in this memory area according to the memory map. Nevertheless the DLL has been loaded into the rather low address 0xa0 in the parent. When trying to map this DLL into the same address in the child, it fails. When I rebase Cwd.dll to some other address like 0x6500, then it works for me. Probably the memory at 0x6ee0 is actually used by some Windows DLL at that time. The fact that the DLL got rebased already in the parent is not exactly surprising, just very annoying. I don't think that this has anything to do with ASLR. It's not the way ASLR is documented to work. Setting or resetting the ASLR flag should have no effect from all I can tell. If anything, setting the ASLR flag in the executable should make things worse in case of fork(). This is entirely the good old fork() problem trying to get the memory layout of the child into the same shape as in the parent. This is really a bad problem since it seem to have gotten even worse with W7. I think I'm going to ask MSFT if there's any workaround for this 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: mintty ^H/^? bug
On 6/3/2009 12:52 AM, Andy Koppe wrote: I think there's a minor bug in the way mintty handles the ^H/^? option for the Backspace key. [...] I guess what I could do is remove the setting from the dialog and instead make it a config file or command line option only, because it's not really something that users should normally have to worry about. Does the command line option currently exist? I didn't see it in the docs. I'm asking because I'm going to update the emacs README when I make the next release. I'd like to include up-to-date advice about how to best set up the various cygwin terminals for emacs. Thanks. Ken -- 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] gmp-4.3.1-1 for cygwin-1.7
Dave Korn wrote:
Yaakov (Cygwin/X) wrote:
On 04/06/2009 21:22, David Billinghurst wrote:
As the gmp and mpfr maintainer, can I do anything to fix this?
Are you able to reproduce this? I see you built these with gcc4 but
with a static libgcc; maybe adding -shared-libgcc would help?
This is the same problem we experienced with file-5.0.whatever-it-was just a
little while ago. There is an old bug in ld thst emits relocs that shouldn't
be there when compiling a DLL; these relocs then end up getting turned into
invalid addresses by rebase, which has no reason to believe there's anything
incorrect about them and probably nothing it could do even if it did.
If you build with fresh binutils from CVS head, the created DLL doesn't have
the problematic reloc. We're rushing out a new binutils release just as soon
as PR977 can be resolved.
cheers,
DaveK
I could reproduce this problem. A rebaseall broke gcc-4. Reinstalling
the gmp DLLs fixed it. I didn't have any problem with the mpfr DLLs.
I have rebuilt gmp with CVS binutils and -shared-libgcc. This fixes the
problem for me. Could someone (Yaakov?) download the new DLLs in
libgmp3-4.3.1-1.tar.bz2 and libgmpxx4-4.3.1-2.tar.bz2 (below) and
confirm the fix.
# Full gmp package ###
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
wget -x -nH --cut-dirs=1 \
${D}/gmp/gmp-4.3.1-2-src.tar.bz2 \
${D}/gmp/gmp-4.3.1-2.tar.bz2 \
${D}/gmp/setup.hint \
${D}/gmp/libgmpxx4/libgmpxx4-4.3.1-2.tar.bz2 \
${D}/gmp/libgmpxx4/setup.hint \
${D}/gmp/libgmp3/libgmp3-4.3.1-2.tar.bz2 \
${D}/gmp/libgmp3/setup.hint \
${D}/gmp/libgmp-devel/libgmp-devel-4.3.1-2.tar.bz2 \
${D}/gmp/libgmp-devel/setup.hint
--
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/
Using emacs in a terminal window
I've answered several questions in recent weeks about how to use emacs in a terminal window. To try to clarify this, I plan to put some suggestions in /usr/share/doc/Cygwin/emacs.README the next time I update the emacs packages. The current draft is appended below. Please let me know if you see any inaccuracies or if anything could be stated more clearly. Ken -- Usage suggestions: 1. For best results, install the emacs-X11 package and run emacs under X windows (by typing 'emacs' in an xterm window, for instance). 2. If you use emacs in a terminal window, the following settings are recommended; without them, some keystrokes may not work as you expect: - mintty: Put BackspaceSendsDEL=1 in your .minttyrc file. - xterm: Invoke xterm with -xrm *backarrowKey:false or put 'XTerm*backarrowKey: false' in your .Xdefaults file. Once xterm is started, give the command 'stty erase ^?'. (These suggestions are only relevant if you invoke emacs with the -nw option in an xterm window or if you have not installed emacs-X11.) - rxvt: Invoke rxvt with the -backspackey DEC option or put 'Rxvt*backspacekey: DEC' in your .Xdefaults file. - Cygwin console (the window you get by using the Cygwin desktop shortcut): Make sure your CYGWIN environment variable contains tty before you start the console. Even then, some keystrokes will not work as expected, such as the C-M-key combinations. A workaround is to use the ESC prefix to simulate the Alt (Meta) key. If you want C-M-a, for instance, type ESC C-a. 3. If you follow the advice above, C-h should work as the help key. (In the case of the Cygwin console, this applies only to Cygwin 1.7, starting with the cygwin-1.7.0-49 release.) If C-h doesn't produce help, the function key F1 is an alternative. -- 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: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
Corinna Vinschen wrote: I can reproduce the unable to remap on W7RC by running `cygport automake1.11-1.11-10 compile'. Uhhh...I'm glad to hear that? Or not... The culprit in my case is always the same DLL, a run-time loaded perl DLL called Cwd.dll. Even after rebaseall, it still doesn't work because the Windows Loader tries to load the DLL into an entirely different address. You did reboot, right? IIRC Windows only calculates the new base address(es) for dynbase-marked DLLs loaded after a boot. Also to turn off dynbase for a particular DLL, you have to reboot after removing the dynbase flag, so that the OS forgets about its randomized Image Base computed for the current boot session, when it had the +dynbase flag. When examining the memory layout of the parent, it stands out that Cwd.dll was already loaded into another address than the DLLs base address. The base addr of Cwd.dll is 0x6ee0, the end address would be 0x6ee08000. Is that the ASLR-computed Image Base, or the one reported by objdump from the file on disk? See below. There's no other DLL in this memory area according to the memory map. Nevertheless the DLL has been loaded into the rather low address 0xa0 in the parent. When trying to map this DLL into the same address in the child, it fails. Right. ASLR isn't putting the DLL in the correct location *in the parent*. (See below). When I rebase Cwd.dll to some other address like 0x6500, then it works for me. Probably the memory at 0x6ee0 is actually used by some Windows DLL at that time. The fact that the DLL got rebased already in the parent is not exactly surprising, just very annoying. I don't think that this has anything to do with ASLR. It's not the way ASLR is documented to work. Setting or resetting the ASLR flag should have no effect from all I can tell. If anything, setting the ASLR flag in the executable should make things worse in case of fork(). ASLR works on DLLs, not EXEs IIRC. peflagsall by default doesn't even set +dynbase on EXEs. echo Note: peflagsall will NOT set the dynamicbase flag on executables, nor will echo it set the tsaware flag on dlls. If you must do this, use peflags itself At each boot, an entirely new random starting location is computed (call it the uber-base address). Then, as each dynbase-marked DLL is first loaded into memory for this boot session, it is rebased to the next available memory location starting at the uber-base address. These new base addresses are remembered for each DLL. In effect, the OS pretends that the Image Base is the new randomized Base address; obviously for this initial load of any given dynbase-marked DLL, the Base address will be equal to the (random) Image Base. Since the new (random) Image Base is hopefully NOT the same as the actual, on-disk Image Base, the DLL will have had relocations updated even though a Process Viewer will report that the in-memory DLL's Base addr == its Image Base -- it's just that the (new) Image Base is the ASLR-directed lie. So, *after* a reboot following marking cygwin DLLs with dynbase, IF you have *ever* successfully loaded Cwd.dll into memory, then that slot -- the new random base address for Cwd -- is forever [*] reserved for Cwd.dll and no other (dynbase-marked) DLL, including windows ones, should ever be allowed by the OS to conflict with that reserved slot. At least, until you run out of ASLR-tracked memory addrs. You can tell what the ASLR-reserved base address for a DLL is by looking at a running process (e.g. in sysinterals process viewer) that has loaded the DLL, and look at what PV reports is the Image Base. (It ought to match the reported 'Base' address, if ASLR is working). However, this 'Image Base' will be *different* from what objdump reports when examining the DLL on disk. That's your proof that ASLR has computed a new (random) base address for this DLL, for this boot session: the claimed Image Base of an in-memory DLL doesn't match the objdump-reported Image Base of the DLL on disk. [*] at least until the next reboot. This is entirely the good old fork() problem trying to get the memory layout of the child into the same shape as in the parent. Right -- but the problem is that ASLR is not setting up the memory layout the way that it promised to, in the parent. This is really a bad problem since it seem to have gotten even worse with W7. Crap. I think I'm going to ask MSFT if there's any workaround for this problem. If my understanding of ASLR is correct, then ASLR *ought* to have solved this problem, except for systems with a LOT of dynbase-marked DLLs that have been loaded during the same boot session, such that you run out of ASLR-tracked addresses (The ASLR mappings are shared across all processes, are persistent for the entire logon session, I think -- so you could eventually run out). But IMO it is not working, for some reason, with the perl DLLs. Note that it's not always Cwd.dll. If you
Re: FAQ 4.46, applications interfere with subversion or not?
On 6/5/2009 2:08 AM, Corinna Vinschen wrote: On Jun 4 14:33, David Rothenberger wrote: On 6/3/2009 8:37 AM, David Rothenberger wrote: On 6/3/2009 8:20 AM, masc wrote: When using cygwin's cvs2svn with subversion (1.6.2 r37639) while running Avira AntiVir (http://www.avira.com/en/pages/index.php), svnadmin is failing sporadically due to permission failure moving files. The subversion code base has some hacks to retry various file operations to work around this issue. These hacks are enabled for a Windows build but not for Cygwin. I've attempted to port these hacks to Cygwin, but I may have missed an error code or three, thus not retrying some errors that should be retried. I just uploaded a new version of Subversion for 1.5 with a fix for the retry patch. I had missed a case when moving files. Are you using Cygwin 1.5 or 1.7? I have disabled this hack in the 1.7 build because I was hoping 1.7's more robust file renaming and deleting code would come to the rescue. It turns out that these problems still occur with 1.7, although less frequently, so I've also released new Subversion packages for 1.7 with the updated retry patch added. Did we discuss this already? No. Can you nail down the problem into a simple testcase? I kinda doubt it. Subversion is using APR to move a file, and the error occurs only sporadically if some other Windows program (e.g., virus scanner) has the file that's being moved open. Do you expect that to work with 1.7? -- David Rothenberger daver...@acm.org Oh what wouldn't I give to be spat at in the face... -- a prisoner in Life of Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FAQ 4.46, applications interfere with subversion or not?
On Jun 5 07:45, David Rothenberger wrote: On 6/5/2009 2:08 AM, Corinna Vinschen wrote: Can you nail down the problem into a simple testcase? I kinda doubt it. Subversion is using APR to move a file, and the error occurs only sporadically if some other Windows program (e.g., virus scanner) has the file that's being moved open. Do you expect that to work with 1.7? Depends on how the Windows program opens the file. If the file has been opened with all sharing flags off, there's not the faintest chance to move the file to another location. Everything depends on the ability to open the file for deletion. 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: How to run GNU Emacs from Windows icon
David Karr wrote: I now need to set up Windows desktop icons that can start these processes. I managed to get XEmacs working, with the following command line: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe Why the insistence on running bash? Why not simply run Xemacs? That's what I do at work and it works fine for me. However, when I try to do something similar for GNU Emacs, it fails immediately. When I tried running the analogous command from the DOS prompt, I got this: - C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Again, why run bash first then run emacs? -- Andrew DeFaria http://defaria.com Press any key to continue or any other key to quit... -- 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] segfault with gfortran 4.3.2 when compiling a simple test case
Gustavo Seabra wrote: I'm having problems with gfortran: $ gfortran --version GNU Fortran (GCC) 4.3.2 20080827 (beta) 2 Copyright (C) 2008 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -O0 -fno-second-underscore -o testp testp.f gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. If you have rebased, please reinstall libgmp/libmpfr. This looks like the same as: http://cygwin.com/ml/cygwin/2009-06/msg00202.html 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: How to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Andrew DeFaria Sent: Friday, June 05, 2009 8:47 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon David Karr wrote: I now need to set up Windows desktop icons that can start these processes. I managed to get XEmacs working, with the following command line: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe Why the insistence on running bash? Why not simply run Xemacs? That's what I do at work and it works fine for me. It may not produce any difficult symptoms with XEmacs itself, but without that I don't get a normal login shell out of the box. However, when I try to do something similar for GNU Emacs, it fails immediately. When I tried running the analogous command from the DOS prompt, I got this: - C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Again, why run bash first then run emacs? Again, so I get a login shell. In any case, this has no effect on the symptom. I tried doing this without bash, and it fails in exactly the same way. 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Yaakov (Cygwin/X) wrote: I'm just taking over libssh2, and it will be updated to 1.0 very soon. Thanks, because my own (naive) attempt failed on the configure stage, because of expr dumping core. Marc -- View this message in context: http://www.nabble.com/Re%3A-Re%3A-Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23850368p23890972.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] segfault with gfortran 4.3.2 when compiling a simple test case
On Fri, Jun 5, 2009 at 12:01 PM, Dave Korndave.korn.cyg...@googlemail.com wrote: Gustavo Seabra wrote: I'm having problems with gfortran: $ gfortran --version GNU Fortran (GCC) 4.3.2 20080827 (beta) 2 Copyright (C) 2008 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -O0 -fno-second-underscore -o testp testp.f gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. If you have rebased, please reinstall libgmp/libmpfr. This looks like the same as: http://cygwin.com/ml/cygwin/2009-06/msg00202.html cheers, DaveK Thanks, that solved it. Gustavo. -- 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: [Fwd: [1.7] wcwidth failing configure tests]
IWAMURO Motonori wrote: 2009/5/21 Thomas Wolff t...@towo.net: Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. The problem with this is 1. As you say, there is no standard. But, - I think that my proposal doesn't violate any specification. I think it does. Part of the locale information is the charmap (called codepage on DOS/Windows). It may be implicit like with LC_CTYPE=zh_CN which defines GB2312 as its charmap, but it is typically explicit like in en_US.UTF-8 - the intention is that the codepage information should be the same for all locales having thbe UTF-8 (or any other) charmap. So you cannot freely change width information among locales with the same charmap. Also, if ja_JP.UTF-8 would mean CJK width, how would you specify a working locale setting for a terminal that does not run a CJK width font but should yet use other Japanese settings? E.g. with rxvt which does not support CJK width. However, there is one resort within the locale mechanism that can be used; the locale syntax allows for an optional modifier which can be used to specify deviations, e.g. de_DE has charmap ISO-8859-1 de...@euro has charmap ISO-8859-15 uz_UZ has charmap ISO-8859-1 uz...@cyrillic has charmap UTF-8 aa_ER and aa...@saaho both have charmap UTF-8 (with some other difference). Thus you could define e.g. ja_jp.ut...@cjk or ja_jp.ut...@cjkwidth to indicate CJK width properties. I guess this is the most compliant way to go. - I heard that there is an existing implementation that behave like my proposal. (Sorry, I didn't hear the system name.) Even if so, I think the way I described is more compatible with the locale mechanism as used elsewhere. 2. If you wish to handle character widths compliant with the terminal ? your application is running in, there is no guarantee that your ? assumption of CJK width (or the actual locale setting if that model ? would be implemented) does indeed reflect the terminal's width properties. Yes, I understand it, too. My proposal is completely workaround. But it is the best solution because we have no specification/standard for my wish. A well-chosen option like above, that stays within the described standard options, would be best accepted by other communities, I think, and could be established for this purpose. 3. In mintty, you can dynamically change width properties by selecting ? different fonts; mintty changes CJK width behaviour according to certain ? font properties. static configuration in your shell using a locale ? variable would not reflect this change It is no problem because we -- most Japanese language users -- need not change the settings of mintty and locale after first setup. We set LANG=ja_JP.UTF-8 and select a Japanese font for mintty. In any case, mined running in mintty will detect CJK width itself, regardless of locale setting, with coming versions of both programs even when it gets changed on-the-fly :) ? b) Determine the actual CJK width behaviour dynamically. That's what ? ? ?mined does (in addition to other width property detection in general). It is the best solution. I think that we need specify the following: - the escape sequence about language context for terminal emulater. -- setting language context -- getting language context -- getting capability of language context (context is fixed, static or dynamic / acceptable languages) - new multilingualized string/terminal API for terminal based applications. This sounds complicated. With my proposal, an application that wishes to auto-adjust on width properties (maybe even when changing) and which (unlike mined) uses the system wcwidth functions could proceed as follows: * Detect CJK width by using a simple test string width detection. * (Optional) When receiving a SIGWINCH signal (future version of MinTTY), repeat this detection. * If e.g. LC_CTYPE starts with ja_JP.UTF-8, call setlocale with either ja_jp.ut...@cjkwidth or ja_JP.UTF-8. The application would need to stay with the same locale prefix ja_JP... because there is no reasonable way to choose a completely different locale, which is another reason to just use the modifier suffix, rather than reserving the complete ja_JP... setting for CJK width. Advantage of this approach: The system does not have to care about this issue and can just follow the locale setting. And, we need rewrite too many applications by new API. Well, alternatively, the system could follow the approach outlined above, but maybe that's not the proper level to do it (?) I'm not happy with the idea of a cygwin-specific solution (or workaround). I think that it is not cygwin-specific solution. As I tried to suggest above, using UTF-8 for different width data on one system would be quite specific, using the @ modifier syntax would not. Kind regards,
Re: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
[Caution, another long reply. For those just looking for a simple workaround, skip to line 86 of the mail body.] On Jun 5 10:56, Charles Wilson wrote: Corinna Vinschen wrote: I can reproduce the unable to remap on W7RC by running `cygport automake1.11-1.11-10 compile'. Uhhh...I'm glad to hear that? Or not... The culprit in my case is always the same DLL, a run-time loaded perl DLL called Cwd.dll. Even after rebaseall, it still doesn't work because the Windows Loader tries to load the DLL into an entirely different address. You did reboot, right? IIRC Windows only calculates the new base No. Because *none* of my DLLs is marked to be ASLR compatible. I'm testing what happens OOTB. The entire problem starts already in the parent when the DLL base address is 0x6ee0. The parent inevitably rebases the DLL to a very low address like 0xa0 or even 0x90 at load time. The child then fails to map the DLL to the same address. However, if I rebase the DLL to some other spot, like 0x6500, then the DLL is loaded at that address exactly, and everything works fine. I still don't think this has anything to do with ASLR. ASLR only complicates the picture. AFAICS, there's no guarantee that the address computed by ASLR will help forever. It only eases the underlying problem by chance if the addresses happen to have a low chance for collision. The problem is not the fact that the DLL is rebased at all in the parent. Even though in my case the address range 0x6ee0-0x6ee08000 isn't taken by another DLL, it could be taken by memory dynamically allocated by one of the formerly loaded DLLs. The real shit starts with the fact that W7 (and Vista, too, apparently) rebases the DLL to an address which is so very low in the address space of the application. This is uncomfortably near to where the process heap is expected to be. When Vista was new, we had the problem already in a somewhat different way. Note this comment in Cygwin's heap.cc: /* For some obscure reason Vista and 2003 sometimes reserve space after calls to CreateProcess overlapping the spot where the heap has been allocated. This apparently spoils fork. The behaviour looks quite arbitrary. Experiments on Vista show a memory size of 0x37e000 or 0x1fd000 overlapping the usual heap by at most 0x1ed000. So what we do here is to allocate the heap with an extra slop of (by default) 0x40 and set the appropriate pointers to the start of the heap area + slop. A forking child then creates its heap at the new start address and without the slop factor. Since this is not entirely foolproof we add a registry setting heap_slop_in_mb so the slop factor can be influenced by the user if the need arises. */ This problem with dynamically linked DLLs looks quite similar. Some space after the heap is reserved in the child which wasn't reserved in the parent. If Vista/W7 would refrain from using the lowest available address in the parent already, the entire problem might go away (aka occurs very, very seldom) I think I'm going to ask MSFT if there's any workaround for this problem. If my understanding of ASLR is correct, then ASLR *ought* to have solved this problem, except for systems with a LOT of dynbase-marked DLLs that have been loaded during the same boot session, such that you run out of ASLR-tracked addresses (The ASLR mappings are shared across all processes, are persistent for the entire logon session, I think -- so you could eventually run out). As I mentioned above, I don't think that ASLR can solve this problem once and for all. Whereever any DLL is rebased to by the ASLR mechanism, there's a chance that the address is already taken in the child when LoadLibrary is called for the dynamically loaded DLL. But IMO it is not working, for some reason, with the perl DLLs. Note that it's not always Cwd.dll. If you reboot, rename Cwd.dll to something else, and keep going, a few things will happen: 1) perl won't work quite right, because the Cwd.dll really is needed by the scripts that 'use Cwd;' 2) ignoring that, keep going. Eventually the remap problem will hit another perl DLL. In my case, Posix.dll. Here's another thought: I examined the address layout of the perl process again, and it struck me as weird that the base addresses of all the DLLs which get dynamically loaded by perl are so near together. It looks like the problem is actually tightened by the order in which the DLLs are rebased by rebaseall, and the order in which the DLLs are loaded into the running process. Some perl DLL (Dumper.dll?) allocates additional memory and that's right after it's own image. That's where Cwd.dll is based to. Cwd.dll gets rebased and ... poof. What I did then was to change the offset to rebaseall: ash$ rebaseall -o 0x2 (default is 0x1) Then I reinstalled /bin/cyggmp-3.dll and reran cygport. This time it ran fine. This is still w/o ASLR flags. In
Re: GCC --enable-auto-import problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Huang Bambo wrote, On 5.6.2009 3:02:
In cygwin 1.7:
1. download db-4.7.25 from oracle at
http://www.oracle.com/database/berkeley-db/index.html (havn't tested
on other version)
2. configure like : ../dist/configure --prefix=/home/Bambo/db-for-1.7
--enable-cxx --enable-pthread_api
3. make, it will take you a few minutes
4. write a program like :
#include db_cxx.h
int main( void )
{
Db db( NULL, 0 );
return 0;
}
5.compile like :g++ -o t test.cpp -L/home/Bambo/db-for-1.7/lib
-ldb_cxx -I/home/Bambo/db-for-1.7/include
will compile and link ok with information:
Info: resolving typeinfo for std::exception by linking to
__imp___ZTISt9exception (auto-import)
/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
warning: auto-importing has been activated without
--enable-auto-import specified on the command line.
This should work unless it involves constant data structures
referencing symbols from auto-imported DLLs.
and the file t.exe can't run, direct run in windows command shell will
report can't load with error code 0x0005.
( use:ldd t.exe to find dlls used by the file will hung ldd)
6.compile like:g++ -o t test.cpp -L/home/Bambo/db-for-1.7/lib -ldb_cxx
-I/home/Bambo/db-for-1.7/include -Wl,--enable-auto-import
Then everything goes fine.
ldd t.exe will report:
$ ldd t.exe
ntdll.dll = /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c92)
kernel32.dll = /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80)
cygwin1.dll = /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL = /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77da)
RPCRT4.dll = /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e5)
Secur32.dll = /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fc)
cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0x67f0)
cygstdc++-6.dll = /usr/bin/cygstdc++-6.dll (0x6c48)
Who can tell me why??? Everything goes fine under cygwin 1.5 with
gcc3(gcc4 not tested), even
without -Wl,--enable-auto-import
This is a known problem. The explanation is rather technical and long, IIRC.
Just use -Wl,--enable-auto-import for all GCC 4.3 compiled code and you are
fine.
- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
iFYEAREIAAYFAkopTLkACgkQhQBMvHf/WHn+QADfZdJ2NcGAByHR0/ci1VPbHV4T
4hk3rxUlHl6ObADg2K6ViJnTxXfC+n5PhGR24BB9SkN4sJgv47fmjg==
=1zce
-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: grep -f option is not working in release of grep (2.5.3-1)
On Thu, Jun 04, 2009 at 10:17:19PM -0700, Tulasi Ram wrote: I have tried by using below command. It didn?t work. $ grep -E -v -f C:\Log\FindDeploymentErrors_Exclude.txt CM_Setup2.log | grep -E -f C:\Log\FindDeploymentErrors_Error.txt -n 1C:\Log\cc.txt Pattern file( FindDeploymentErrors_Error.txt)is below.. A member could not be added Access is denied cacl: object Cannot add rows to Error: ERROR: Error from Error occurred while loading document is not recognized as an external command is not recognized as an internal or external command Usage: recognized If I use above command to search patterns in CM_Setup2.log, the output file cc.txt is showing only last pattern( recognized) search results. It seems it is overwriting one pattern results with next pattern results and finally shows the last pattern. I need the all pattern search results in same file i.e., cc.txt. Attached is the cygcheck.out file FYI Did you make sure that the lines end with \n rather than \r\n? You can run FindDeploymentErrors_Exclude.txt through d2u to make sure. 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: Using emacs in a terminal window
On Fri, Jun 05, 2009 at 10:29:33AM -0400, Ken Brown wrote: I've answered several questions in recent weeks about how to use emacs in a terminal window. To try to clarify this, I plan to put some suggestions in /usr/share/doc/Cygwin/emacs.README the next time I update the emacs packages. The current draft is appended below. Please let me know if you see any inaccuracies or if anything could be stated more clearly. Hmm. You know I wonder if it's time that we set up a per-package FAQ on cygwin.com. It seems like the slightly more than clueless people sometimes go to the Cygwin FAQ for help on individual packages so maybe we could have a FAQ for things like emacs, bash, ssh there. At the very least we could make the package documentation available. 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: Cygwin SSH Multiple Users
http://cygwin.com/acronyms/#TOFU. Reformatted. Huang Bambo wrote: 2009/6/5 Holikar, Sachin (ext) sachin dot holikar dot ext AT siemens dot com: ^- http://cygwin.com/acronyms/#PCYMTNQREAIYR Thanks. Hello, We reinstalled WINXP and CYGWIN with another dumps. But still not able to start the sshd service. Really frustrated as we followed exact steps given in most of the internet help pages. So whats going wrong , is there any way to find out what more is needed or so? Where can we have the sshd logs. One file we found is /var/log/sshd.log ...But its empty... Please suggest. use command /usr/sbin/sshd to try start first This seems to be a favorite thing to suggest/try lately. I suppose because it's a common debugging option on most Unix/Linux distributions. But on Cygwin, just suggesting the above and leaving the rest to the otherwise uninitiated is like helping someone out of a hole by handing them a shovel and telling them too dig. If you ever plan to run 'sshd' as a service (as configuring using 'ssh-host-config' will do for you), this will only work if you do the above as the user that will run the service. On XP, that's SYSTEM. So you need to start a SYSTEM-owned shell using AT before the above isn't just a recipe for more headaches. See the email archives for details if you're not sure how to start a SYSTEM-owned shell. Or just stop and ask yourself why you need to know how to do this (beyond intellectual curiousity of course! ;-) ) And of course if you're starting 'sshd' using any configuration other than the 'ssh-host-config' script, then you should really know what you're doing, as I outlined in my response from yesterday: http://cygwin.com/ml/cygwin/2009-06/msg00175.html Since the OP is having difficulties with 'sshd' on Cygwin and is asking for help here, I would surmise that he falls into the category of the uninitiated in this instance. So, my recommendations are to: 1. Look at 'ssh-host-config' and note all the directories that it does chown on. 2. Run 'ssh-host-config' to configure 'sshd'. Take the defaults unless you have a very good reason not to. 3. Check after the script completes that the ownerships of the directories found in (1) above are as 'ssh-host-config' set them. On XP systems, the $(run_service_as} user is SYSTEM. Following random guides found on the Internet to configure Cygwin's 'sshd' is not supported by this list. Reading the openssh readme in '/usr/share/doc/Cygwin' is only supported documentation. If you prefer to use another source for your configuration information, please avail yourself of any support/help from the site where you got this information. -- 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod wrote: Yaakov (Cygwin/X) wrote: I'm just taking over libssh2, and it will be updated to 1.0 very soon. Thanks, because my own (naive) attempt failed on the configure stage, because of expr dumping core. Marc If you have rebased, please reinstall libgmp/libmpfr. This looks like the same as: http://cygwin.com/ml/cygwin/2009-06/msg00209.html 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] gmp-4.3.1-1 for cygwin-1.7
David Billinghurst wrote:
I have rebuilt gmp with CVS binutils and -shared-libgcc. This fixes the
problem for me. Could someone (Yaakov?) download the new DLLs in
libgmp3-4.3.1-1.tar.bz2 and libgmpxx4-4.3.1-2.tar.bz2 (below) and
confirm the fix.
# Full gmp package ###
D=http://billinghurst.customer.netspace.net.au/cygwin-1.7
wget -x -nH --cut-dirs=1 \
${D}/gmp/gmp-4.3.1-2-src.tar.bz2 \
${D}/gmp/gmp-4.3.1-2.tar.bz2 \
${D}/gmp/setup.hint \
${D}/gmp/libgmpxx4/libgmpxx4-4.3.1-2.tar.bz2 \
${D}/gmp/libgmpxx4/setup.hint \
${D}/gmp/libgmp3/libgmp3-4.3.1-2.tar.bz2 \
${D}/gmp/libgmp3/setup.hint \
${D}/gmp/libgmp-devel/libgmp-devel-4.3.1-2.tar.bz2 \
${D}/gmp/libgmp-devel/setup.hint
This doesn't appear to work for me with the existing expr.exe; I think you
should just use new binutils but keep the static libgcc linkage. The static
ctors in the DLL appear to be getting run twice, which is bad.
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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Dave Korn-6 wrote: If you have rebased, please reinstall libgmp/libmpfr. Er... rebased what? I have rebased all, only expr cannot be rebased (no symbols). Can one rebase optimized executables? Anyway, I used wget as advertised, but what then? And besides... gmp tar jft gmp-4.3.1-2.tar.bz2 bzip2: Data integrity error when decompressing. Input file = (stdin), output file = (stdout) It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. tar: Child returned status 2 tar: Exiting with failure status due to previous errors gmp bzip2 -tvv gmp-4.3.1-2.tar.bz2 gmp-4.3.1-2.tar.bz2: [1: huff+mtf data integrity (CRC) error in data You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. gmp bzip2recover gmp-4.3.1-2.tar.bz2 bzip2recover 1.0.5: extracts blocks from damaged .bz2 files. bzip2recover: searching for block boundaries ... block 1 runs from 80 to 0 block 2 runs from 2169475 to 0 bzip2recover: splitting into blocks writing block 1 to `rec1gmp-4.3.1-2.tar.bz2' ... writing block 2 to `rec2gmp-4.3.1-2.tar.bz2' ... bzip2recover: finished gmp bzip2 -tvv gmp-4.3.1-2.tar.bz2 gmp-4.3.1-2.tar.bz2: [1: huff+mtf data integrity (CRC) error in data You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. Marc -- View this message in context: http://www.nabble.com/Re%3A-Re%3A-Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23850368p23892886.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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod wrote: Dave Korn-6 wrote: If you have rebased, please reinstall libgmp/libmpfr. Er... rebased what? I have rebased all, only expr cannot be rebased (no symbols). Can one rebase optimized executables? Anyway, I used wget as advertised, but what then? I think Dave was suggesting that you use 'setup.exe' to reinstall these packages. -- 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: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
On 05/06/2009 11:35, Corinna Vinschen wrote: Here's another thought: I examined the address layout of the perl process again, and it struck me as weird that the base addresses of all the DLLs which get dynamically loaded by perl are so near together. It looks like the problem is actually tightened by the order in which the DLLs are rebased by rebaseall, and the order in which the DLLs are loaded into the running process. Some perl DLL (Dumper.dll?) allocates additional memory and that's right after it's own image. That's where Cwd.dll is based to. Cwd.dll gets rebased and ... poof. What I did then was to change the offset to rebaseall: ash$ rebaseall -o 0x2 (default is 0x1) Then I reinstalled /bin/cyggmp-3.dll and reran cygport. This time it ran fine. This is still w/o ASLR flags. In this configuration, I can reproduce running cygport successfully every time. Alright, I tried a few combinations; finally -b 0x6100 -d -o 0x2 (IOW descending from cygwin1's base) got autotools (and KDE4, which was also suffering heavily from this) working again. Mind you, that leaves my last dll at 0x189f, and I'm still not finished with KDE yet. I'm sure more work is needed on this, but in the meantime this workaround seems to do the job. Thanks! Yaakov -- 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod wrote: Dave Korn-6 wrote: If you have rebased, please reinstall libgmp/libmpfr. Er... rebased what? I have rebased all, only expr cannot be rebased (no symbols). Can one rebase optimized executables? No, but expr.exe depends on libgmp and that's where the problem probably lies. Anyway, I used wget as advertised, but what then? As Larry says, I meant reinstall the standard distro versions. 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: How to run GNU Emacs from Windows icon
On 6/5/2009 11:58 AM, David Karr wrote: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Again, why run bash first then run emacs? Again, so I get a login shell. In any case, this has no effect on the symptom. I tried doing this without bash, and it fails in exactly the same way. I have a few other suggestions if you want to keep trying to track this down: 1. Send cygcheck output (as an attachment) as requested at http://cygwin.com/problems.html 2. Try emacs -q to make sure there's nothing in your initialization file(s) causing the problem. 3. Try emacs 23: http://sourceware.org/ml/cygwin/2009-05/msg00475.html http://sourceware.org/ml/cygwin/2009-05/msg00635.html Ken -- 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: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
Corinna Vinschen wrote: On Jun 5 10:56, Charles Wilson wrote: You did reboot, right? IIRC Windows only calculates the new base No. Because *none* of my DLLs is marked to be ASLR compatible. I'm testing what happens OOTB. OK, that makes sense. The entire problem starts already in the parent when the DLL base address is 0x6ee0. The parent inevitably rebases the DLL to a very low address like 0xa0 or even 0x90 at load time. The child then fails to map the DLL to the same address. However, if I rebase the DLL to some other spot, like 0x6500, then the DLL is loaded at that address exactly, and everything works fine. I still don't think this has anything to do with ASLR. ASLR only complicates the picture. AFAICS, there's no guarantee that the address computed by ASLR will help forever. It only eases the underlying problem by chance if the addresses happen to have a low chance for collision. ??? One of the side effects of ASLR is to, in effect, perform a custom rebase for every dynbase-enabled DLL, that is (a) unique to the usage pattern of your machine workflow since you (booted/logged on), and (b) includes not just cygwin DLLs but also all normal system DLLs so marked, and (c) persists for the entirety of the current boot/logon session. This means very little chance of collision at all, AFIACT, at least not any that arise from (new)ImageBase+codesize. For ASLR, all dynbase DLLs (including cygwin ones) get mapped to the range 0x5000 to 0x7800. If something ends up at 0x90, either with +dynbase/ASLR or without, it's not directly related to ASLR... The problem is not the fact that the DLL is rebased at all in the parent. Even though in my case the address range 0x6ee0-0x6ee08000 isn't taken by another DLL, it could be taken by memory dynamically allocated by one of the formerly loaded DLLs. Really? This would have to be by virtue of some call OTHER than to cygwin's malloc, right? Because I thought cygwin maintained a single process heap way down low in memory...it's hardly likely for that heap to clash with 0x5000...0x7800 (or, for the original rebase, non-ASLR scenario, 0x6800...downwards), for small allocations like this (e.g. where your solution of adding a single page to the DefaultOffset size as a buffer helps). If it's a cygwin-linked DLL doing this (e.g. Dumper.dll) maybe it's a bug in that DLL, using the wrong mechanism to allocate memory (e.g. a direct call to VirtualAlloc or to (deprecated) GlobalAlloc or LocalAlloc functions?) ...Hmm, perl itself (incl. Dumper.dll) doesn't seem to. The real shit starts with the fact that W7 (and Vista, too, apparently) rebases the DLL to an address which is so very low in the address space of the application. But why did it do this at all? In the normal rebase scenario (and assuming no dynamically allocated memory sucking up 0x6800-level space), sure -- I could see some other system DLL interfering with where rebase wanted to put, e.g. Cwd.dll. But in the ASLR scenario, almost all system DLLs are marked +dynbase, so ASLR is supposed to auto-rebase the entire working set of +dynbase DLLs (system AND win32app AND cygwin), which avoids that issue. I think the answer to the question is what you have discovered about dynamic (e.g. non-dll-image-related) allocations up in the ImageBase memory area(s). This is uncomfortably near to where the process heap is expected to be. When Vista was new, we had the problem already in a somewhat different way. Note this comment in Cygwin's heap.cc: [snip] This problem with dynamically linked DLLs looks quite similar. Some space after the heap is reserved in the child which wasn't reserved in the parent. Hmmm... If Vista/W7 would refrain from using the lowest available address in the parent already, the entire problem might go away (aka occurs very, very seldom) I think I'm going to ask MSFT if there's any workaround for this problem. If my understanding of ASLR is correct, then ASLR *ought* to have solved this problem [snip] As I mentioned above, I don't think that ASLR can solve this problem once and for all. Whereever any DLL is rebased to by the ASLR mechanism, there's a chance that the address is already taken in the child when LoadLibrary is called for the dynamically loaded DLL. Ack -- with the caveat that IF that is the case, it most likely isn't related to the actual DLL images loaded up in that area of the child's memory. I still think ASLR would/should/does solve THAT issue. It's just that there may be some non-Image-related memory that is getting reserved -- perhaps by the DLLs themselves during a custom DllMain DLL_PROCESS_ATTACH? No...the only DllMain is in win32/perllib.c, which AFAICT is not used on cygwin builds. ...digging in to perl source code... Hmm...depending on configure options and platform defaults, perl may implement it own memory manager (which can be/is used by extensions, like
RE: How to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Friday, June 05, 2009 11:37 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon On 6/5/2009 11:58 AM, David Karr wrote: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Again, why run bash first then run emacs? Again, so I get a login shell. In any case, this has no effect on the symptom. I tried doing this without bash, and it fails in exactly the same way. I have a few other suggestions if you want to keep trying to track this down: 1. Send cygcheck output (as an attachment) as requested at http://cygwin.com/problems.html Attached. 2. Try emacs -q to make sure there's nothing in your initialization file(s) causing the problem. No difference. Considering the failure happens even before the window comes up, I would have been shocked if it made a difference. 3. Try emacs 23: http://sourceware.org/ml/cygwin/2009-05/msg00475.html http://sourceware.org/ml/cygwin/2009-05/msg00635.html I'll proceed with that. Thanks. cygcheck.out 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: How to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Friday, June 05, 2009 11:37 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon On 6/5/2009 11:58 AM, David Karr wrote: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Again, why run bash first then run emacs? Again, so I get a login shell. In any case, this has no effect on the symptom. I tried doing this without bash, and it fails in exactly the same way. I have a few other suggestions if you want to keep trying to track this down: 3. Try emacs 23: http://sourceware.org/ml/cygwin/2009-05/msg00475.html http://sourceware.org/ml/cygwin/2009-05/msg00635.html Ok, I've done some searching, but I can't figure out how to get this package. I've never installed experimental packages before. The latest available from setup.exe, even in experimental state, is 22.1-3. I assume I'm looking for -23.0.92-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: How to run GNU Emacs from Windows icon
On 6/5/2009 3:25 PM, David Karr wrote: 1. Send cygcheck output (as an attachment) as requested at http://cygwin.com/problems.html Attached. Two things jump out at me. First, it's clear from the environment variables that you ran cygcheck from a shell within emacs. I don't think it matters in this case, but in general it's probably best not to do that, since you want to see the environment *before* starting emacs. Emacs changes some of the variables. More importantly, I see this: CYGWIN = 'check_case:strict tty' I don't know whether this could be causing your problem, but the cygwin user's guide (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html) says the following: check_case:level - THIS OPTION IS DEPRECATED. Don't use it unless you know what you're doing and don't see any way around it. And even then, this option is error prone, slows down Cygwin and not well maintained. On 6/5/2009 3:44 PM, David Karr wrote: Ok, I've done some searching, but I can't figure out how to get this package. I've never installed experimental packages before. The latest available from setup.exe, even in experimental state, is 22.1-3. I assume I'm looking for -23.0.92-2? Just run setup.exe, locate the emacs packages, and repeatedly click on the version number in the New column. It cycles through all of the choices, one of which should be 23.0.92-2. Ken Ken -- 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: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
On Jun 5 14:44, Charles Wilson wrote: Corinna Vinschen wrote: However, if I rebase the DLL to some other spot, like 0x6500, then the DLL is loaded at that address exactly, and everything works fine. I still don't think this has anything to do with ASLR. ASLR only complicates the picture. AFAICS, there's no guarantee that the address computed by ASLR will help forever. It only eases the underlying problem by chance if the addresses happen to have a low chance for collision. One of the side effects of ASLR is to, in effect, perform a custom rebase for every dynbase-enabled DLL, that is (a) unique to the usage pattern of your machine workflow since you (booted/logged on), and (b) includes not just cygwin DLLs but also all normal system DLLs so marked, and (c) persists for the entirety of the current boot/logon session. This means very little chance of collision at all, AFIACT, at least not any that arise from (new)ImageBase+codesize. For ASLR, all dynbase DLLs (including cygwin ones) get mapped to the range 0x5000 to 0x7800. If something ends up at 0x90, either with +dynbase/ASLR or without, it's not directly related to ASLR... That's what I'm trying to say. ASLR is probably helping in the normal use case. But if the DLL's ALSR memory slot is taken by something else (for instance, a non-ASLR DLL), the new DLL will have to be relocated by the system, same as without ASLR. It might be a helpful technique, but it's far from a one-size-fits-all solution. The problem is not the fact that the DLL is rebased at all in the parent. Even though in my case the address range 0x6ee0-0x6ee08000 isn't taken by another DLL, it could be taken by memory dynamically allocated by one of the formerly loaded DLLs. Really? This would have to be by virtue of some call OTHER than to cygwin's malloc, right? In theory, yes, but not necessarily. malloc does not use the heap exclusively. Big chunks of memory (128K) are allocated using mmap() with the MAP_PRIVATE|MAP_ANONYMOUS flags. Private anonymous maps are implemented using VirtualAlloc with the MEM_TOP_DOWN flag. Because I thought cygwin maintained a single process heap way down low in memory...it's hardly likely for that heap to clash with 0x5000...0x7800 (or, for the original rebase, non-ASLR scenario, 0x6800...downwards), for small allocations like this (e.g. where your solution of adding a single page to the DefaultOffset size as a buffer helps). It's definitely not a collision with the heap which results in rebasing the DLL in the parent. If it's a cygwin-linked DLL doing this (e.g. Dumper.dll) maybe it's a bug in that DLL, using the wrong mechanism to allocate memory (e.g. a direct call to VirtualAlloc or to (deprecated) GlobalAlloc or LocalAlloc functions?) ...Hmm, perl itself (incl. Dumper.dll) doesn't seem to. The real shit starts with the fact that W7 (and Vista, too, apparently) rebases the DLL to an address which is so very low in the address space of the application. But why did it do this at all? In the normal rebase scenario (and assuming no dynamically allocated memory sucking up 0x6800-level space), sure -- I could see some other system DLL interfering with where rebase wanted to put, e.g. Cwd.dll. That's not the case. There's no DLL loaded into the address in question. At least not if I ask WinDbg. Either the memory is taken by something else (I don't know what it is), or the OS decides that DLLs shouldn't spoon with each other (think of the children) and rebases the DLL for decency. [...time passes...] WinDbg confirms that the memory is taken by something else. Dumper.dll is located in the area 0x6ede - 0x6eded000. The next three pages from 0x6eded000 - 0x6edf000 are free. The following memory region from 0x6edf - 0x6ee01000 (68K, huh?) consists of commited R/W pages allocated in a single allocation call. Examining the content of the commited memory region starting at 0x6edf shows something surprising. After a couple of arbitrary bytes, there's a 4 byte value 68, followed by the WCHAR string \\?\C:\cygwin\lib\perl5\5.10\i686-cygwin\auto\Data\Dumper\Dumper.dll which is exactly 68 wide characters long. The entire reminder of the memory region is set to 0. The fact that the path has a leading \\?\ points to something in the Cygwin DLL allocating that memory, perhaps in dlopen. But why at this memory address?!? Some perl DLL (Dumper.dll?) allocates additional memory and that's right after it's own image. That's where Cwd.dll is based to. Cwd.dll gets rebased and ... poof. Right then. So...why? Seems odd that the dynamic allocation is occuring up high and not down in user_heap. Absolutely. Especially after finding what's in that memeory region... Could it be possible that cygwin's dlopen (or fork) implementation is Not that I can see. The memory for the data storing the loaded DLLs is loaded from the
RE: How to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Friday, June 05, 2009 2:04 PM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon On 6/5/2009 3:25 PM, David Karr wrote: 1. Send cygcheck output (as an attachment) as requested at http://cygwin.com/problems.html Attached. Two things jump out at me. First, it's clear from the environment variables that you ran cygcheck from a shell within emacs. I don't think it matters in this case, but in general it's probably best not to do that, since you want to see the environment *before* starting emacs. Emacs changes some of the variables. Regenerated, and reattached. More importantly, I see this: CYGWIN = 'check_case:strict tty' I don't know whether this could be causing your problem, but the cygwin user's guide (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html) says the following: check_case:level - THIS OPTION IS DEPRECATED. Don't use it unless you know what you're doing and don't see any way around it. And even then, this option is error prone, slows down Cygwin and not well maintained. Hmph. When I read the documentation for a framework, I almost always go directly to the PDF, if it's available. The PDF doesn't say anything about this being deprecated. I wouldn't have used it if it had. If I'm interpreting the modification date on the file properly, this PDF hasn't been regenerated in 5 years. Looking at this also made me realize a silly mistake I was making, in that I was setting CYGWIN in my .bashrc, not in my system env vars. I fixed that, and also removed check_case, but it had no obvious effect. On 6/5/2009 3:44 PM, David Karr wrote: Ok, I've done some searching, but I can't figure out how to get this package. I've never installed experimental packages before. The latest available from setup.exe, even in experimental state, is 22.1-3. I assume I'm looking for -23.0.92-2? Just run setup.exe, locate the emacs packages, and repeatedly click on the version number in the New column. It cycles through all of the choices, one of which should be 23.0.92-2. Ah, yes. It's been a while. Proceeding. cygcheck.out 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: How to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Friday, June 05, 2009 11:37 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon On 6/5/2009 11:58 AM, David Karr wrote: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/emacs.exe emacs: Terminal type cygwin is not defined. If that is not the actual type of terminal you have, use the Bourne shell command `TERM=... export TERM' (C-shell: `setenv TERM ...') to specify the correct type. It may be necessary to do `unset TERMINFO' (C-shell: `unsetenv TERMINFO') as well. Again, why run bash first then run emacs? Again, so I get a login shell. In any case, this has no effect on the symptom. I tried doing this without bash, and it fails in exactly the same way. I have a few other suggestions if you want to keep trying to track this down: 1. Send cygcheck output (as an attachment) as requested at http://cygwin.com/problems.html 2. Try emacs -q to make sure there's nothing in your initialization file(s) causing the problem. 3. Try emacs 23: http://sourceware.org/ml/cygwin/2009-05/msg00475.html http://sourceware.org/ml/cygwin/2009-05/msg00635.html Ok, I've installed Emacs 23. The results are sort of better, but worse. Running it now, which actually runs emacs-X11 through a link, looks like emacs -nw. It's definitely not using X11. If I run it from a Bash prompt in rxvt, it comes up fine (with the minor annoyance that setting the frame-position at 0,0 doesn't mean the same thing as it did before), and the fonts are definitely nicer. :) Ken -- 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/
RE: How to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Friday, June 05, 2009 11:37 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon 3. Try emacs 23: http://sourceware.org/ml/cygwin/2009-05/msg00475.html http://sourceware.org/ml/cygwin/2009-05/msg00635.html For now, I can at least hide most of the cruft by using this as my shortcut command: C:\cygwin\bin\rxvt.exe -geometry 1x1 -e /usr/bin/bash --login -c emacs Along with hacking the frame-position to 4,26 (I imagine this will only be a temporary problem). This gives me a usable window without additional manual steps. (Now I just have to find a reasonable Windows icon for it.) -- 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: How to run GNU Emacs from Windows icon
On 6/5/2009 5:46 PM, David Karr wrote: Ok, I've installed Emacs 23. The results are sort of better, but worse. Running it now, which actually runs emacs-X11 through a link, looks like emacs -nw. It's definitely not using X11. If you have an X server running and the DISPLAY environment variable set appropriately, emacs-X11 will use X11. Try this: Start the X server and then type 'emacs' in an xterm window. This should cause emacs to open in a new window, using X11. The startemacs.bat that I sent you earlier in the thread achieves the same effect (as long as the X server is running). Ken -- 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: ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]
Corinna Vinschen wrote: Not good. I'm puzzled where this allocated 68K region is exactly coming from, but it really looks like something which occurs in or near dlopen. I'm going to debug this further tomorrow. I guess that goes without saying, but I'd be glad for any help. I'll just suggest that these problems can often be debugged more easily in windbg than gdb, what with gflags/appverifier heap tracking, !vad, !heap, and related commands. The gflags FLG_HEAP_ENABLE_TAG_BY_DLL might come in handy 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/
Problem on compiling fcitx, undefined reference to '_XpmCreateImageFromData'
Dear All When compiling fcitx 3.6.0 with gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) but some errors. I have libXpm and libiconv installed. Any one have same problem and could give some advice? Thank a lot ! ERROR MESSAGE === $ make make all-recursive make[1]: Entering directory `/home/Administrator/tools/fcitx-3.6.0-rc' Making all in doc make[2]: Entering directory `/home/Administrator/tools/fcitx-3.6.0-rc/doc' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/Administrator/tools/fcitx-3.6.0-rc/doc' Making all in xpm make[2]: Entering directory `/home/Administrator/tools/fcitx-3.6.0-rc/xpm' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/Administrator/tools/fcitx-3.6.0-rc/xpm' Making all in lib make[2]: Entering directory `/home/Administrator/tools/fcitx-3.6.0-rc/lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/Administrator/tools/fcitx-3.6.0-rc/lib' Making all in src make[2]: Entering directory `/home/Administrator/tools/fcitx-3.6.0-rc/src' gcc -DPKGDATADIR=\/usr/local/share/fcitx\ -I. -I.. -I. -I../lib -I../xpm -O2 -fno-strength-reduc e -g -O2-D_USE_XFT -Wall -MT InputWindow.o -MD -MP -MF .deps/InputWindow.Tpo -c -o InputWindow.o InputWindow.c mv -f .deps/InputWindow.Tpo .deps/InputWindow.Po gcc -DPKGDATADIR=\/usr/local/share/fcitx\ -I. -I.. -I. -I../lib -I../xpm -O2 -fno-strength-reduc e -g -O2-D_USE_XFT -Wall -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c mv -f .deps/main.Tpo .deps/main.Po gcc -DPKGDATADIR=\/usr/local/share/fcitx\ -I. -I.. -I. -I../lib -I../xpm -O2 -fno-strength-reduc e -g -O2-D_USE_XFT -Wall -MT tools.o -MD -MP -MF .deps/tools.Tpo -c -o tools.o tools.c tools.c:695: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c:700: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c:736: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c:741: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c:1064: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c:1069: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c:1074: warning: dereferencing type-punned pointer will break strict-aliasing rules tools.c: In function `ConvertGBKSimple2Tradition': tools.c:1811: warning: dereferencing type-punned pointer will break strict-aliasing rules mv -f .deps/tools.Tpo .deps/tools.Po gcc -DPKGDATADIR=\/usr/local/share/fcitx\ -I. -I.. -I. -I../lib -I../xpm -O2 -fno-strength-reduc e -g -O2-D_USE_XFT -Wall -MT about.o -MD -MP -MF .deps/about.Tpo -c -o about.o about.c about.c: In function `InitWindowProperty': about.c:127: warning: passing arg 2 of `libiconv' from incompatible pointer type mv -f .deps/about.Tpo .deps/about.Po gcc -O2 -fno-strength-reduce -g -O2-D_USE_XFT -Wall -lXpm -o fcitx.exe IC.o ime.o InputWindow.o KeyList.o main.o MainWindow.o MyErrorsHandlers.o punc.o py.o PYFA.o pyMapTable.o pyParser.o sp.o to ols.o ui.o table.o xim.o qw.o vk.o about.o QuickPhrase.o AutoEng.o extra.o internalVersion.o ../lib/ libXimd.a -lX11 InputWindow.o: In function `DrawInputWindow': /home/Administrator/tools/fcitx-3.6.0-rc/src/InputWindow.c:444: undefined reference to `_XpmCreateIm ageFromData' /home/Administrator/tools/fcitx-3.6.0-rc/src/InputWindow.c:436: undefined reference to `_XpmCreateIm ageFromData' MainWindow.o: In function `DrawMainWindow': /home/Administrator/tools/fcitx-3.6.0-rc/src/MainWindow.c:250: undefined reference to `_XpmCreateIma geFromData' /home/Administrator/tools/fcitx-3.6.0-rc/src/MainWindow.c:198: undefined reference to `_XpmCreateIma geFromData' /home/Administrator/tools/fcitx-3.6.0-rc/src/MainWindow.c:193: undefined reference to `_XpmCreateIma geFromData' MainWindow.o:/home/Administrator/tools/fcitx-3.6.0-rc/src/MainWindow.c:241: more undefined reference s to `_XpmCreateImageFromData' follow ui.o: In function `InitX': /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:129: undefined reference to `_libiconv_open' ui.o: In function `CreateFont': /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:250: undefined reference to `_XftFontOpen' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:254: undefined reference to `_XftFontOpen' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:258: undefined reference to `_XftFontOpen' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:263: undefined reference to `_XftFontOpen' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:268: undefined reference to `_XftFontOpen' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:272: undefined reference to `_XftDrawCreate' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:249: undefined reference to `_XftFontClose' /home/Administrator/tools/fcitx-3.6.0-rc/src/ui.c:271: undefined reference to
Re: Using emacs in a terminal window
An alternative to providing instructions for a workaround would be to modify the default initialization files that are provided with the terminal emulators. For example, rxvt comes with the following file: $ cygcheck -l rxvt | grep app-defaults /etc/defaults/etc/X11/app-defaults/Rxvt The post-installation script of rxvt could be changed to install the default, system initialization file 'Rxvt' into the directory /etc/X11/app-defaults/. That file could be modified to include the following lines: Rxvt.backspacekey: ^? Rxvt.ttyModes: erase ^? With those changes (modifying the file and copying it into /etc/X11/app-defaults), rxvt should give the behavior that is expected for the backspace key and the Control-H key combination, both at the shell prompt and in terminal-mode Emacs. Similar solutions can likely be devised for xterm and mintty, but I do not have those packages installed. These solutions would need to be incorporated into new versions of the terminal emulator packages, which would require the agreement of those package maintainers. -- 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: How to run GNU Emacs from Windows icon
David Karr wrote: -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Andrew DeFaria Sent: Friday, June 05, 2009 8:47 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon David Karr wrote: I now need to set up Windows desktop icons that can start these processes. I managed to get XEmacs working, with the following command line: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe Why the insistence on running bash? Why not simply run Xemacs? That's what I do at work and it works fine for me. It may not produce any difficult symptoms with XEmacs itself, but without that I don't get a normal login shell out of the box. And why do you require a normal login shell? Here's what I have for my shortcut that starts up XEmacs: C:\Cygwin\bin\run.exe xemacs. Nothing else is required. I don't need to login. I'm logged in already. I just need to edit files... Again, why run bash first then run emacs? Again, so I get a login shell. In any case, this has no effect on the symptom. I tried doing this without bash, and it fails in exactly the same way. You have not defined what exactly your symptom is WRT xemacs. You stated: I managed to get XEmacs working, with the following command line: C:\cygwin\bin\bash.exe --login -c C:/cygwin/bin/xemacs-21.4.22.exe Then went on to describe how it fails with emacs (not xemacs) because emacs and a problem with your terminal type. I would think that xemacs doesn't care as much about terminal type. Is xemacs failing with the same error about terminal type? What is TERM set to for you? (Me: it's set to cygwin). -- Andrew DeFaria http://defaria.com Computers make very fast, very accurate mistakes. -- 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: mintty ^H/^? bug
2009/6/5 Ken Brown: I guess what I could do is remove the setting from the dialog and instead make it a config file or command line option only, because it's not really something that users should normally have to worry about. Does the command line option currently exist? No. Sorry, I should have been more clear. For 0.4, things will stay as they are, i.e. ^H is the default, and the dialog setting is the most obvious way of changing it. If the xterm terminfo entry changes on Cygwin 1.7, I'll change the MinTTY accordingly. (Actually at that point I might just remove the setting altogether and instead implement the DECBKM control sequence for changing the backspace code, which MinTTY doesn't currently support.) 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/
