Re: svn 1.7.10-1 on x86_64 does not work
Corinna Vinschen wrote: > On Aug 28 09:05, Robert Klemme wrote: >> On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger >> wrote: >>> On 8/27/2013 9:04 AM, Robert Klemme wrote: $ svn --version /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory >>> >>> Check that you have libneon27 installed. That's missing from >>> the dependencies. If that doesn't work, try "cygcheck >>> /usr/bin/svn", which might tell you what else is missing. >> >> $ fgrep -i libneon /etc/setup/installed.db $ cygcheck $(type -p >> svn) >/dev/null cygcheck: track_down: could not find >> cygneon-27.dll >> >> Bingo! I installed it and now it works. > > So libneon27 should be added to subversion's setup.hint requires? Sigh. I guess. It's only required by 1.7, not by the latest 1.8, so it's not caught by cygport automatically. (I know, I know, I should review the auto-generated requires.) -- David Rothenberger daver...@acm.org This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance. -- Steven Wright, comedian -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: run-1.3.0-1
> Just for completeness, run-1.3 does not even work on windows 7 U 64b. I'm having stackdump issues with run.exe as well. WinXP 32 bit service pack 3 run.exe 1.3.0-1 $ cat ./run.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=6110BAE6 eax=200202D0 ebx=622F7273 ecx=6126C994 edx=0090 esi=752F005F edi=200202D0 ebp=2000 esp=00224F10 program=P:\cygwin\bin\run.exe, pid 4640, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 2000 6110BAE6 (611FE648, DF0DF046, 6126C780, ) End of stack trace -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-24.3.1 crashes on talking to Google
On 8/28/2013 9:50 AM, Zdzislaw Meglicki wrote: Ken Brown wrote: > What's the exact error message? > And can you reproduce this starting with 'emacs -Q'? Yes, the error shows when emacs is started with -Q. Here it is: $ emacs-x11 -Q ** (emacs-x11:32728): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. This is a harmless warning, which sometimes occurs. (I don't know when or why. It comes from atk. You can apparently suppress it with "export NO_AT_BRIDGE=1". See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15154#11 Then Ken wrote: > It looks like you're using at least one obsolete variable. > I suggest you start by reading the emacs documentation > on smtpmail, especially the section on authentication. Indeed. I see many changes compared to emacs-21. Not only is smtpmail-auth-credentials obsolete. smtpmail-starttls-credentials is obsolete too. Yes, this part of my .emacs code will have to be rewritten. A suggestion to Emacs/Cygwin maintainers/developers: please, give us an example of a working up-to-date .emacs code for making emacs send e-mail through Google. It's a popular way of doing it nowadays. This is not specific to Cygwin. If it belongs anywhere, it should be in the emacs manual. I just looked at the section "Emacs speaks SMTP" in the smtpmail documentation, and the instructions look pretty clear to me. What happens if you follow those instructions, replacing "mail.example.org" with "smtp.gmail.com"? If there's anything Cygwin-specific that goes wrong, then I'll try to fix it or add something to /usr/share/doc/emacs/README.Cygwin, whatever is appropriate. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trying to solve my cygheap base mismatch issue
On 8/28/2013 9:29 AM, Tony Whyte wrote: Hi All I have resorted to attempting a fresh install of a base Cygwin because I suddenly started getting cygheap errors (after year of use) when I launched the cygwin terminal window. Im pretty sure it was related to a non-Cygwin dll, PGHook.dll, that had grabbed a slot at 0x6110 thus crowding out cygwin1.dll from its preferred base address of 0x6100. This displacement however undermines a successful install also , as post install scripts try to execute. (See error snippet below). Visited: 49 nodes out of 49 while creating dependency order. Dependency order of packages: libgcc1 libiconv2 libintl8 alternatives base-cygwin libstdc++6 libattr1 cygwin libgmp3 libgmp10 libmpfr4 libreadline7 gawk tzcode coreutils terminfo libncursesw10 bash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils dash diffutils dos2unix editrights zlib0 file gettext libpcre0 grep groff gzip ipc-utils libncurses10 less liblzma5 login xz man mintty rebase run tar vim-minimal which 2013/08/27 08:37:31 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/000-cygwin-post-install.sh" 6 [main] mkdir (2500) C:\cygwin\bin\mkdir.exe: *** fatal error - cygheap base mismatch detected - 0x7A0970/0x720970. To add some context I show listdlls.exe output for a dash.exe process below. dash.exe pid: 1768 Command line: "C:\cygwin\bin\dash.exe" BaseSize Path 0x0040 0x1a000 dash.exe 0x7c90 0xb2000 ntdll.dll 0x7c80 0xf6000 kernel32.dll 0x6110 0x3f000 PGHook.dll 0x7e41 0x91000 USER32.dll 0x77f1 0x49000 GDI32.dll 0x0049 0x4b cygwin1.dll 0x77dd 0x9b000 ADVAPI32.dll 0x77e7 0x93000 RPCRT4.dll 0x77fe 0x11000 Secur32.dll 0x6800 0x36000 rsaenh.dll 0x77c1 0x58000 msvcrt.dll 0x76bf 0xb000PSAPI.DLL Its a bit of a catch-22 situation and Im looking for suggestions how to get a completely successful Install done. Things to try, in order of preference: 1. Uninstall Avecto Privilege Guard. 2. Disable the Windows service that loads PGHook.dll. 3. Rebase PGHook.dll to a new location. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is there going to be rxvt-unicode and terminus-fonts pkgs on 64bits?
On 8/28/2013 2:20 AM, Arthur Tu wrote: Also lftp and inet-tools(which includes telnet). I'm currently working on inetutils. It's slow going, as the cygwin version is *heavily* patched from stock, and I'm forward-porting those changes from inetutils-1.7 to inetutils-1.9. Stay tuned. I just noticed rxvt-unicode is not available on cygwin-64bits, although it is on cygwing-32bits. Are there plans to include it? rxvt-unicode: yes, eventually. There are some library dependencies that have to be produced first. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-24.3.1 crashes on talking to Google
Ken Brown wrote: > What's the exact error message? > And can you reproduce this starting with 'emacs -Q'? Yes, the error shows when emacs is started with -Q. Here it is: $ emacs-x11 -Q ** (emacs-x11:32728): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Then Ken wrote: > It looks like you're using at least one obsolete variable. > I suggest you start by reading the emacs documentation > on smtpmail, especially the section on authentication. Indeed. I see many changes compared to emacs-21. Not only is smtpmail-auth-credentials obsolete. smtpmail-starttls-credentials is obsolete too. Yes, this part of my .emacs code will have to be rewritten. A suggestion to Emacs/Cygwin maintainers/developers: please, give us an example of a working up-to-date .emacs code for making emacs send e-mail through Google. It's a popular way of doing it nowadays. Greetings to all, Gustav http://perth.ovpit.indiana.edu/gustav -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trying to solve my cygheap base mismatch issue
Hi All I have resorted to attempting a fresh install of a base Cygwin because I suddenly started getting cygheap errors (after year of use) when I launched the cygwin terminal window. Im pretty sure it was related to a non-Cygwin dll, PGHook.dll, that had grabbed a slot at 0x6110 thus crowding out cygwin1.dll from its preferred base address of 0x6100. This displacement however undermines a successful install also , as post install scripts try to execute. (See error snippet below). Visited: 49 nodes out of 49 while creating dependency order. Dependency order of packages: libgcc1 libiconv2 libintl8 alternatives base-cygwin libstdc++6 libattr1 cygwin libgmp3 libgmp10 libmpfr4 libreadline7 gawk tzcode coreutils terminfo libncursesw10 bash findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils dash diffutils dos2unix editrights zlib0 file gettext libpcre0 grep groff gzip ipc-utils libncurses10 less liblzma5 login xz man mintty rebase run tar vim-minimal which 2013/08/27 08:37:31 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/000-cygwin-post-install.sh" 6 [main] mkdir (2500) C:\cygwin\bin\mkdir.exe: *** fatal error - cygheap base mismatch detected - 0x7A0970/0x720970. To add some context I show listdlls.exe output for a dash.exe process below. dash.exe pid: 1768 Command line: "C:\cygwin\bin\dash.exe" BaseSize Path 0x0040 0x1a000 dash.exe 0x7c90 0xb2000 ntdll.dll 0x7c80 0xf6000 kernel32.dll 0x6110 0x3f000 PGHook.dll 0x7e41 0x91000 USER32.dll 0x77f1 0x49000 GDI32.dll 0x0049 0x4b cygwin1.dll 0x77dd 0x9b000 ADVAPI32.dll 0x77e7 0x93000 RPCRT4.dll 0x77fe 0x11000 Secur32.dll 0x6800 0x36000 rsaenh.dll 0x77c1 0x58000 msvcrt.dll 0x76bf 0xb000PSAPI.DLL Its a bit of a catch-22 situation and Im looking for suggestions how to get a completely successful Install done. Thanks for any inputs Tony -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-24.3.1 crashes on talking to Google
The version of the Cygwin fetchmail is 6.3.22+NLS. Running ldd on it shows:
ntdll.dll, KERNEL32.DLL, KERNELBASE.dll, cygwin1.dll, cygintl-8.dll,
cygiconv-2.dll
When I run it against my .fetchmailrc, it complains about the "ssl" line and
says
that it's not enabled.
The version of my own fetchmail, the one I compiled myself, is 6.3.26+SSL+NLS.
Running ldd on it shows all the above plus
cygcrypto-1.0.0.dll, cygssl-1.0.0.dll, cygz.dll
But, as I said, I do not have a problem with fetchmail. The problem, as I
described
in my message, is with emacs *sending* mail through Google. On making an attempt
it crashes. I can't even view diagnostics.
On the other hand, my emacs can send mail through a simple non-SSL SMTP server
I run on another machine. So, it's something with how the latest emacs
communicates
with Google that's broken. Posting through Google worked like a charm under
emacs-21.?.? The current emacs version is
emacs 24.3.1 (x86_64-unknown-cygwin)
I posted my .emacs configuration for sending mail through google in my previous
message, but here it is again for completeness:
(setq starttls-use-gnutls t)
(setq send-mail-function 'smtpmail-send-it
message-send-mail-function 'smtpmail-send-it
smtpmail-starttls-credentials
'(("smtp.gmail.com" 587 nil nil))
smtpmail-auth-credentials
(expand-file-name "~/.authinfo")
smtpmail-default-smtp-server "smtp.gmail.com"
smtpmail-smtp-server "smtp.gmail.com"
smtpmail-smtp-service 587
smtpmail-debug-info t)
(require 'smtpmail)
===
On Wednesday, August 28, 2013 5:23 AM David Carrricajo <> wrote:
On Tue, Aug 27, 2013 at 6:53 PM, Zdzislaw Meglicki <> wrote:
>Should I change something here? My fetchmail gets e-mail from Google
>too and this works fine. But I had to install my own version of fetchmail
>because the one provided with Cygwin didn't support SSL.
>
Which version? from version 5 fetchmail does support SSL
>Greetings,
>Gustav
>http://perth.ovpit.indiana.edu/gustav
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: svn 1.7.10-1 on x86_64 does not work
On Aug 28 09:05, Robert Klemme wrote: > On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger wrote: > > On 8/27/2013 9:04 AM, Robert Klemme wrote: > >> $ svn --version > >> /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open > >> shared object file: No such file or directory > > > > Check that you have libneon27 installed. That's missing from the > > dependencies. If that doesn't work, try "cygcheck /usr/bin/svn", which > > might tell you what else is missing. > > $ fgrep -i libneon /etc/setup/installed.db > $ cygcheck $(type -p svn) >/dev/null > cygcheck: track_down: could not find cygneon-27.dll > > Bingo! I installed it and now it works. So libneon27 should be added to subversion's setup.hint requires? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpG2V7lpW9pb.pgp Description: PGP signature
liblto_plugin.so not found under cygwin64 while works under cygwin32
Hi, I have a problem of things behaving unexpectedly differently under Cygwin32 and Cygwin64. I would appreciate some advice as how to debug it. The scenario (run separately on two installations - Cygwin32 and Cygwin64): 1. I compile GCC 4.8.1 cross compiler for ARM under Cygwin using exactly the same "configure ...", "make" and "make install" commands (AFAIU this results in x86 and x86_64 host versions respectively). 2. When I use the Cygwin32 version for my project everything works fine. 3. But when I use the Cygwin64 version I get the following linking error "arm-none-eabi-g++ : fatal error : -fuse-linker-plugin, but liblto_plugin.so not found" 4. Both installations have the following files present: /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/cc1.exe /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/cc1plus.exe /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/collect2.exe /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/cyglto_plugin-0.dll /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/install-tools /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/liblto_plugin.dll.a /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/liblto_plugin.la /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper.exe /usr/arm-none-eabi/libexec/gcc/arm-none-eabi/4.8.1/lto1.exe Any advice? Many thanks, Vasili -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: svn 1.7.10-1 on x86_64 does not work
On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger wrote: > On 8/27/2013 9:04 AM, Robert Klemme wrote: >> $ svn --version >> /usr/bin/svn.exe: error while loading shared libraries: ?: cannot open >> shared object file: No such file or directory > > Check that you have libneon27 installed. That's missing from the > dependencies. If that doesn't work, try "cygcheck /usr/bin/svn", which > might tell you what else is missing. $ fgrep -i libneon /etc/setup/installed.db $ cygcheck $(type -p svn) >/dev/null cygcheck: track_down: could not find cygneon-27.dll Bingo! I installed it and now it works. > If all that fails, follow the instructions at > http://cygwin.com/problems.html. The cygcheck output will help us figure > out what else is missing. There does not seem to be anything else missing. Thank you, David! Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: emacs-nox hogs CPU if backgrounded during compile
On 27/08/2013 8:06 AM, Ken Brown wrote: On 8/27/2013 4:28 AM, Ryan Johnson wrote: On 17/08/2013 2:41 PM, Ryan Johnson wrote: Hi all, The following STC causes emacs-nox to peg a CPU indefinitely. Emacs remains responsive, but C-c C-k doesn't kill the compile; you have to exit emacs to remove the "Compiling" status. Killing the buffer or starting a new compile offers to kill the offending process, but doesn't. Attaching gdb shows an endless loop inside kernelbase.dll!RaiseException, but provides no other clues that I could see. 1. emacs-nox -Q 2. M-x compile 3. C-a C-k sleep 1; echo hi 4. ^Z (before the sleep finishes) 5. fg (after the sleep finishes) I don't know if this is related to limited pipe buffering, but I don't think so: it has always worked in the past, and the the 3-4 bytes required to buffer up "hi\n" is hardly onerous. $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ cygcheck -cd bash 4.1.11-1 cygwin1.7.24-1 emacs 24.3-5 mintty1.2-beta1-1 > Ping... is anyone else at least able to reproduce this? I can reproduce this on both x86 and x86_64, even without the "echo hi". Update: the problem only occurs if output arrives while emacs is stopped. So, "echo hi; sleep 5; echo ho" will not cause the problem if you ^Z/fg during the gap. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
