Re: XServer draws to incorrect window when using VirtuaWin
On 13 August 2010 11:38, Pete sneakypet...@gmail.com wrote: VirtuaWin (http://virtuawin.sourceforge.net/) is a virtual desktop manager for Windows that lets you switch between several virtual desktops, similar to those provided in KDE Gnome. When switching between desktops that have CygwinX windows open, occasionally the Xserver draws to the wrong window. This is difficult to describe, so will continue with an example: Using Windows 7, Cygwin/X v1.8.0 Steps to reproduce: 1) Install VirtuaWin from http://virtuawin.sourceforge.net/ 2) Start the CygwinX server 3) Open a (DOS) cygwin window 4) Type xterm twice, to open two xterm windows. Maximise these two windows to full screen. 5) Move one of these windows to desktop2 6) Type ping google.com -n 1000 to get a stream of data appearing in the xterm window on desktop2 7) Go back to desktop1, and make sure the DOS cygwin window is selected 8) Switch back to desktop2. The ping xterm window should be selected. 9) Switch back to desktop1. The cygwin window should be selected. What should happen: The empty xterm session on desktop1 should be displayed in the window behind the cygwin window What happens: The ping data stream appears in the xterm window on desktop1, and continues receiving updates every second. Selecting the xterm window causes the ping data to disappear and the empty xterm session to be displayed correctly. This is reproducible every time. The critical thing is that if the xterm window on desktop1 is not selected after a desktop switch, it shows the data from the xterm window on desktop 2. FWIW, this problem doesn't exist with xming, and I haven't seen the issue with any other applications. Any questions, please let me know. Thanks, Pete Is there anything else I can do to help debug this? Unfortunately it is necessary to install VirtuaWin to reproduce the issue, but it's very reproducible. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: No xauth program
Brilliant!!! That did the trick. Thanks so much. This was really driving me crazy. Cheers, -Scott On 9/2/2010 6:48 PM, Jon TURNEY wrote: On 9/2/2010 11:11 AM, Jon TURNEY wrote: On 01/09/2010 20:29, Scott T. Marshall wrote: when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. You might like to try if xauth can actually run successfully? On 02/09/2010 18:56, Scott T. Marshall wrote: Thanks for the suggestion Jon. I don't know exactly what I should ask xauth to do or what syntax is requires (the man page was not completely clear to me), but what I can say is that if I try to execute xauth in an xterm, it gives no errors. I can also say that when I ssh to other linux machines, I can open X applications, but my cygwin/windows 7 x64 box will not forward x windows when someone log onto it. Hmm... it looks like the latest openssh package has the wrong default path to xauth for some reason. As a workaround, you might try adding XAuthLocation=/usr/bin/xauth to /etc/sshd_config and restarting sshd. -- Scott T. Marshall Department Of Geology Appalachian State University 572 Rivers St. Boone, NC 28608 http://www.appstate.edu/~marshallst/ ftp://pm.appstate.edu/pub/prog/marshallst/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 So far so good... I've switched monitors several times without problems (both with -resize and without). Thanks! Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 2 23:32, John Carey wrote: On Aug 12 01:11, Corinna Vinschen wrote: On Aug 12 06:54, Andy Koppe wrote: On 11 August 2010 20:55, John Carey wrote: So is your idea that if SetCurrentDirectory() fails because of path length or permissions, then Cygwin would just accept the failure and keep an internal record the POSIX current working directory and use that for all Cygwin calls, not the Win32 notion of current directory? Yes. The question then becomes what to do about the Win32 working directory in that case. Actually, Cygwin accepts *any* directory it can open as CWD: - Directories which can only be opened under SE_BACKUP_NAME. - Directories with a length up to 32768 chars. - Virtual directories, which don't exist at all as filesystem-based paths, like /proc, /cygdrive, etc. In Aug 17 10:15, Corinna Vinschen wrote: I just released 1.7.6-1. ... What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api Thank you very much for the fix! I've been running tests against Cygwin 1.7.6, and then 1.7.7, and those sporadic, non-deterministic failures in CreatePipe did stop after the 1.7.6 upgrade, and are still gone in 1.7.7. I think it's been long enough to conclude that it is not just the non-determinism--it really is fixed, as expected. I understand that this issue opened a can of worms; thanks again for your efforts to overcome those difficulties. I still don't like the final workaround, which is, to set the Win32 CWD to the Cygwin CWD. It would be nice if we could revert that change to the pre-1.7.6 behaviour in a Vista-friendly way. If you ever find out how to make sure that the new handle in the PEB's user parameter block is used even on Vista and later, pray tell me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: OpenSSH-5.6p1-1
On Sep 2 23:49, Jon TURNEY wrote: On 23/08/2010 16:15, Corinna Vinschen wrote: I've just updated the Cygwin version of OpenSSH to 5.6p1-1. This is a new major upstream release. The Cygwin release is created from the vanilla sources. It looks like this update has reverted the default XAuthLocation from /usr/bin/xauth to /usr/X11R6/bin/xauth. You're right. I built that version on a new machine which has no xauth installed, so configure felt back to the default path. I've changed that and upload a new openssh soon. Thanks for the hint, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Inability to delete *or rename* CWD of any program driving me nuts
On Sep 2 14:33, Daniel Colascione wrote: I keep bumping into Cygwin's new inability rename or delete directories that are the CWD of any program. In particular, Emacs will often start background processes like aspell in whatever directory happens to be the default-directory for the current buffer. That program hangs around even after I kill all buffers visiting files in that directory, so even hours after I last edit a file in a directory, I find myself wondering why on earth 'mv' on it hangs. Also, I have (bad?) habit of leaving old terminal windows around, sometimes sitting in directories I later delete or rename. I get rid of them eventually, but having to hunt down and kill them to perform basic filesystem operations is a nuisance. Of course, these annoyances can be worked around, but it was less cumbersome to just allow cwd to be modified. If you read the announcement and followed the discussions on this list, you know why we had to do it. If it helps to share the pain, I don't like it either. Not the faintest. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: simulating console input
On Thu, Sep 02 2010, Larry Hall (Cygwin) wrote: How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. Read http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console. Then add this fact - the SSH server uses ptys. So your program will not work with a single character put in the input buffer. One could envision using 'yes' to fill the buffer of the pipe that the Windows program interprets the pty to be. Perhaps a nicer alternative is to build the problematic program with Cygwin, if that's an option, so that it will understand the pty. Unfortunately, I don't have the source code of the program, so it's no option to patch it. I tested mintty: it does not work. I understand, that there is nothing to do with a pipe to the pty or stdin. I'm thinking of something like this: ConsoleKeypressSimulator.exe --delay 10 --key y DosProgram.exe And for proper operation, the DosProgram needs a y keypress about 10 seconds after begin of execution. So my questions are: - Is it possible to write such a program: ConsoleKeypressSimulator.exe ? - If yes, what is the degree of difficulty to write that? Thanks for your help! Peter -- Contact information: http://pmrb.free.fr/contact/ -- 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: simulating console input
On 3 September 2010 08:53, Peter Münster wrote: Read http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console. Then add this fact - the SSH server uses ptys. So your program will not work with a single character put in the input buffer. One could envision using 'yes' to fill the buffer of the pipe that the Windows program interprets the pty to be. Perhaps a nicer alternative is to build the problematic program with Cygwin, if that's an option, so that it will understand the pty. Unfortunately, I don't have the source code of the program, so it's no option to patch it. I tested mintty: it does not work. I understand, that there is nothing to do with a pipe to the pty or stdin. I'm thinking of something like this: ConsoleKeypressSimulator.exe --delay 10 --key y DosProgram.exe And for proper operation, the DosProgram needs a y keypress about 10 seconds after begin of execution. So my questions are: - Is it possible to write such a program: ConsoleKeypressSimulator.exe ? - If yes, what is the degree of difficulty to write that? I've written a utility called 'conin' that translates pty input to console events. Perhaps that'll do the job. See here: http://groups.google.com/group/mintty-discuss/browse_thread/thread/1f9cf480117b8a0b In any case, it should demonstrate how to generatate console input events. Andy -- 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: simulating console input
On 03.09.2010 10:53, Peter Münster wrote:
So my questions are:
- Is it possible to write such a program: ConsoleKeypressSimulator.exe ?
Try http://www.autohotkey.com/
Or try VBScript/JScript:
$ cat command.js
var process = WScript.CreateObject(WScript.Shell);
process.Run(i-use-gui-command-here --with -a --few args);
WScript.Sleep(1000); process.AppActivate(process.ProcessID);
process.SendKeys({TAB}{TAB}{TAB}{ENTER});
$ cmd /c command.js
- If yes, what is the degree of difficulty to write that?
Try upper.
--
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
How 'exec 1-; exec 2-' work?
I develop gtk app under Windows and in order to run it I need start Cygwin X Windows. To start X Windows I use Makefile rule: .PHONY: cygwin-startx cygwin-startx: XWin -multiwindow But when I invoke this target in native GNU Emacs by M-x compile in *Compilation* buffer I see XWin output and compilation not complete. So next M-x compile Emacs prompt A compilation process is running; kill it? (yes or no) I intuitively change command to exec 1-; exec 2-; XWin -multiwindow and now Emacs compilation finished and server work in background. I really don't understand what magic exec do. Can anyone point me? -- 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: .exe magic in Cygwin
Cygport is rather similar to emerge/ebuild already. You might find it worthwhile to give it a look. I am aware of this. I want come to a solution, that builds me from sources on any of Windows, Mac and Linux. One to rule them all. I did only find Gentoo Prefix to be able to do this. If all you need is a way to install existing Cygwin packages from the command line, you can do that quite well with setup.exe. It has many command line options which help automate the installation process. I hoped so. Probably I will have to use that exessivly to set up the basics. If you want to build a replacement anyway, you should probably delve into why nothing like what you want exists already. This issue comes up repeatedly on this list, so you should be able to find much in the list archives. I found a project called Gentoo on Cygwin. It was abandoned in 2008. http://www.gentoo-wiki.info/HOWTO_Gentoo_on_Cygwin The Gentoo Prefix approach is a little different. It is not a first level, but a second level software manager, completely in the userspace. It sits on it's own prefix as the name tells. It is simply a folder that I can put into any POSIX environment. There is no need to replace all of Cygwin. It is a living project that already works on Mac, Unix and Informix. The missing link is Cygwin. I have documented the current achievements http://en.gentoo-wiki.com/wiki/Prefix/ Al -- 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: simulating console input
On Fri, Sep 03 2010, Andy Koppe wrote: I've written a utility called 'conin' that translates pty input to console events. Perhaps that'll do the job. See here: http://groups.google.com/group/mintty-discuss/browse_thread/thread/1f9cf480117b8a0b Great, it works! It's as easy as echo y | conin DosProgram :) It works also very well with conin net use ... IMHO, this program should be mentioned here: http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console Thank you very much! Thanks also to Oleksandr for the java-script! Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/ -- 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: .exe magic in Cygwin
Right. I applied it the traditional way. Ah, you have to understand this about cygport patches: they only contain patches for the source files, not the autogenerated ones. So they have patches for e.g. Makefile.am, configure.ac; but not for configure or even Makefile.in. It's vitally necessary to autoreconf after applying a patch that you get from a cygport-based package. OK, that's it. As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I rather have to figure out one of those hidden ways. Well, if you're doing it in a POSIX-compatible environment, you should be able to run cygport - with maybe a few minor bugs cropping up, but basically it's just a bunch of shell scripts that invoke the autotools, gcc and binutils, so they should be relatively easy to port to any similar environment. I did once try running cygport on a linux box (with a cross-compiler). I don't remember exactly what went wrong, it didn't work directly out of the box, but it shouldn't be hard to fix. This sounds like a real alternative. Very interesting! It would definitly be worth it's own project group. Then it would be a choice. Al -- 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: How does one change the default shell?
On 02/09/2010 23:29, risin...@nationwide. wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) See From: header! cheers, DaveK -- 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: How to get a script file to use bash and ssh
Greetings, Jeremy Bopp! Assuming, of course, that the necessary entry in /etc/passwd is set correctly. Even if not. Or not set. $ grep $USER /etc/passwd [...]:/cygdrive/c/home/Daemon:/bin/bash $ ls -l /cygdrive/c/home/Daemon ls: cannot access /cygdrive/c/home/Daemon: No such file or directory $ set | grep HOME HOME=/c/home/Daemon HOMEDRIVE=C: HOMEPATH=/home/Daemon $ ls -l $HOME total 8015 drwxr-xr-x 1 Daemon Отсутствует 0 2010-08-29 19:21 Application Data ... The OP sounds pretty green and may have a different idea of his home directory's location than Cygwin deduces, so a little extra hand holding may be in order. :-) May be... but it seems, that cygwin deduction is pretty accurate. -- WBR, Andrey Repin (anrdae...@freemail.ru) 03.09.2010, 13:41 Sorry for my terrible english... -- 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: .exe magic in Cygwin
2010/9/3 Al oss.el...@googlemail.com: Right. I applied it the traditional way. Ah, you have to understand this about cygport patches: they only contain patches for the source files, not the autogenerated ones. So they have patches for e.g. Makefile.am, configure.ac; but not for configure or even Makefile.in. It's vitally necessary to autoreconf after applying a patch that you get from a cygport-based package. OK, that's it. autoreconf terminates with: Can't exec 'aclocal': No such file ... Hmm -- 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: .exe magic in Cygwin
2010/9/3 Al oss.el...@googlemail.com: 2010/9/3 Al oss.el...@googlemail.com: Right. I applied it the traditional way. Ah, you have to understand this about cygport patches: they only contain patches for the source files, not the autogenerated ones. So they have patches for e.g. Makefile.am, configure.ac; but not for configure or even Makefile.in. It's vitally necessary to autoreconf after applying a patch that you get from a cygport-based package. OK, that's it. autoreconf terminates with: Can't exec 'aclocal': No such file ... solved: http://www.mail-archive.com/debian-h...@lists.debian.org/msg19036.html -- 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: How 'exec 1-; exec 2-' work?
On 09/03/2010 02:47 AM, Oleksandr Gavenko wrote: I intuitively change command to exec 1-; exec 2-; XWin -multiwindow I really don't understand what magic exec do. How could it be intuition if you don't know what it does? A better description would be calling it what it was to you at the time - black magic copied from some online example you found. Can anyone point me? 'exec' with just file redirections makes those redirections affect the current shell and all subsequent processes started by the shell. 1- is a POSIX-mandated redirection for closing stdout; likewise 2- for closing stderr. By closing stdout and stderr before starting XWin, you are making it so that XWin no longer ties up your terminal. By the way, you could run this instead: XWin -multiwindow - 2- and get the same effect without the 'exec'. And none of this is cygwin-specific. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- 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: How to get a script file to use bash and ssh
On 9/3/2010 4:50 AM, Andrey Repin wrote: Greetings, Jeremy Bopp! Assuming, of course, that the necessary entry in /etc/passwd is set correctly. Even if not. Or not set. $ grep $USER /etc/passwd [...]:/cygdrive/c/home/Daemon:/bin/bash $ ls -l /cygdrive/c/home/Daemon ls: cannot access /cygdrive/c/home/Daemon: No such file or directory $ set | grep HOME HOME=/c/home/Daemon HOMEDRIVE=C: HOMEPATH=/home/Daemon $ ls -l $HOME total 8015 drwxr-xr-x 1 Daemon Отсутствует 0 2010-08-29 19:21 Application Data ... The OP sounds pretty green and may have a different idea of his home directory's location than Cygwin deduces, so a little extra hand holding may be in order. :-) May be... but it seems, that cygwin deduction is pretty accurate. After looking at it in more detail, I agree that you're most likely correct. Since the OP isn't asking more questions about this, I guess things are working for him in any case. -Jeremy -- 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: export DISPLAY={localWorkstationIP} in mintty
On 9/2/2010 8:37 PM, Andrew DeFaria wrote: On 09/02/2010 03:37 PM, Jeremy Bopp wrote: On 9/2/2010 5:12 PM, PaulHR wrote: I got the standard error. Error: Can't open display: I made sure xWin Server was running Did a -vvv on the ssh and saw nothing for X11 What else can I look at? It would be really helpful if you included a little context from earlier bits of the conversation to which you are responding. I'm going to assume that you responded to my message suggesting you use the -X option to ssh. ;-) It's possible that the corresponding server-side option to allow that feature is disabled. If so, you could try to reconfigure the ssh server. The option to enable is named X11Forwarding and it should be set to yes. If you are not allowed to do that, then your only option is to go back to your original idea of figuring out your local IP. This will require a bit more effort on your part. When you connect to the remote machine, there should be an environment variable named SSH_CLIENT set. It appears to be a space delimited list where the first item is your client's IP address. Given that and assuming your shell is bash on the server, you can use the following to set the DISPLAY environment variable after you open your connection: export DISPLAY=$(echo $SSH_CLIENT | cut -d' ' -f1):0 If that works for you, you may want to put it in your .bashrc or .bash_profile script on the server side so that it happens automatically every time you connect. -Jeremy It's been my experience that if you do not have DISPLAY set before you ssh then you will not have it set after you ssh (usually to localhost:n where n is usually not 0). BTW don't put the IP address in DISPLAY - just set it to DISPLAY=:0. BTW2 X is an awful heavy process to run if your aim is merely to run ASCII terminals. Instead use mintty (or rxvt) and -e ssh remote host instead. I think you may have things a bit confused here. Unless I'm the confused one, the OP wants to open an SSH connection to a remote host and then start an X client there which connects back to his X server under Cygwin. We attempted the simple case of using ssh to tunnel the X connection, but that appeared to have been blocked by the SSH server. The only alternative is to use the local host's IP address in the remote DISPLAY setting to point back to his default X display. I'm not sure what X clients the OP is trying to run, but I don't think they're terminals. The advice provided by Heath in a slightly earlier thread opened by the same OP would have opened a local terminal of some kind to host the ssh connection. Of course, the OP could jump in here and clarify things... ;-) -Jeremy -- 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
[ANNOUNCEMENT] Updated: {libtool/libltdl7}-2.2.11a-1
GNU libtool is a generic library support script. Libtool hides the
complexity of using shared libraries behind a consistent, portable
interface.
This is a bugfix and feature enhancement update.
[[ compiled using gcc-4.3.4-3 ]]
CHANGES SINCE 2.2.7a-15
=
* Updated to latest git master version (2010-09-02,
0f052db3b89835904b95d8336b2491e7b8eef8f7)
* libtool script supports linking with .la files that contain
an '='-indicated sysroot
* Projects using libtool now support a new --with-sysroot=... option
* Largest cygwin patches have been merged upstream
* Remaining (old) patches:
+ allow runtime library flags (like -static-libgcc)
- Yaakov Selkowitz libtool: -{shared,static}-libgcc
http://www.cygwin.com/ml/cygwin/2009-08/msg00243.html
+ [cygwin|mingw] Create UAC manifest files (as modified)
* New patches:
+ Fix linking with -fstack-protector (Yaakov Selkowitz)
http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7330/focus=7341
+ Fix order of PATH manipulation in cwrapper (reported by Jon Turney)
http://cygwin.com/ml/cygwin/2010-07/msg00601.html
* Does not yet support LTO. There is an lto branch upstream, and it is
slated to be merged in to the release branch before 2.2.12 (due RSN)
I'll update again at that time.
Test results -- old tests:
=
All 122 tests passed
(2 tests were not run)
Test results -- new tests:
=
111 tests behaved as expected.
9 tests were skipped.
(no regressions from 2.2.7a-15)
--
Charles Wilson
volunteer libtool maintainer for cygwin
To update your installation, click on the Install Cygwin now link
on the http://cygwin.com/ web page. This downloads setup.exe to
your system. Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is
available starting at this URL.
--
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
R: Packaging error with Octave 3.2.4?
--- Ven 3/9/10, Peter Schuerch ha scritto: Hi, I'm trying to run octave from Cygwin and I'm experiencing problems with apparently missing files. I reported the problem on the octave mailing list, where people suggested it might be a packaging problem (https://www-old.cae.wisc.edu/pipermail/help-octave/2010-September/021507.html) and suggested to bother you guys. $ octave --version GNU Octave, version 3.2.4 Copyright (C) 2009 John W. Eaton and others. [...] I tried the following commands: octave:1 x=rand(1,10); octave:2 y=rand(size(x)); octave:3 T=delaunay(x,y); error: No such file or directory error: called from: error: /usr/share/octave/3.2.4/m/geometry/delaunayn.m at line 55, column 5 error: /usr/share/octave/3.2.4/m/geometry/delaunay.m at line 55, column 11 I have checked, both files (delaunayn.m and delaunay.m) exist. I'm running this version of Cygwin: $ uname -a CYGWIN_NT-5.1 WEST091 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin the output of cygcheck -s -v -r is attached. Many thanks for your help. Peter it seems a problem on my last update of libqhull_5 downgrading from 2010.1-1 to 2009.1.1-1 solves the problem. I will check what is wrong in the interaction of libqhull_5-2010.1-1 and octave Marco -- 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: How does one change the default shell?
On 09/03/2010 09:52 AM, Paul McFerrin wrote: How about the obviousChange the shell listed in the /etc/passwd file for the affected user. I for years had pdksh as my default shell. Yes, I was a long time ATTer, where the ksh was invented. Quit top-posting, and http://cygwin.com/acronyms/#YSHFRTT The OP already made it clear that changing /etc/password was not what he meant (that only changes your interactive shell), rather he was asking how to make /bin/sh be pdksh instead of bash (for all scripts, so that an arbitrary script ./foo can use pdksh features). If a shell script starts with a #! line, then that's the shell that will be used, regardless of the user's /etc/passwd shell or the current setting of $SHELL. And if a shell script does not start with a #! line, then it will be executed with /bin/sh, again regardless of /etc/passwd or $SHELL. So the only way to change the equation is to change /bin/sh, or to use an appropriate #! line in all affected scripts. Personally, I find #! the more robust option (just like I recommend that you should use #!/bin/bash if you intend on using a bash feature, rather than blindly relying on the fact that /bin/sh defaults to bash in cygwin). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- 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: Inability to delete *or rename* CWD of any program driving me nuts
On 9/3/10 12:45 AM, Corinna Vinschen wrote: If you read the announcement and followed the discussions on this list, you know why we had to do it. If it helps to share the pain, I don't like it either. Not the faintest. Of course I have, and I understand the workaround. What I don't understand is why the pipefs technique (for which you had working code, IIRC) wasn't used in the end. Was it the difficulty of changing cygtools to use the new interface? The additional interface complexity? Personally, I'd argue both are worth it. -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 03 12:37 Corinna Vinschen wrote: On Sep 2 23:32, John Carey wrote: In Aug 17 10:15, Corinna Vinschen wrote: I just released 1.7.6-1. ... What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api Thank you very much for the fix! I've been running tests against Cygwin 1.7.6, and then 1.7.7, and those sporadic, non-deterministic failures in CreatePipe did stop after the 1.7.6 upgrade, and are still gone in 1.7.7. I think it's been long enough to conclude that it is not just the non-determinism--it really is fixed, as expected. I understand that this issue opened a can of worms; thanks again for your efforts to overcome those difficulties. I still don't like the final workaround, which is, to set the Win32 CWD to the Cygwin CWD. It would be nice if we could revert that change to the pre-1.7.6 behaviour in a Vista-friendly way. If you ever find out how to make sure that the new handle in the PEB's user parameter block is used even on Vista and later, pray tell me. Thus far the only ideas I have come up with are somewhat shaky and go well beyond the documented Win32 API. (If only there was the equivalent of dup2(), but for Win32 handles!!!) Just how much undocumented behavior is tolerable, do you think? -- John -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On 3 September 2010 08:37, Corinna Vinschen wrote: I still don't like the final workaround, which is, to set the Win32 CWD to the Cygwin CWD. It would be nice if we could revert that change to the pre-1.7.6 behaviour in a Vista-friendly way. If you ever find out how to make sure that the new handle in the PEB's user parameter block is used even on Vista and later, pray tell me. I haven't got the magic bullet of course, but since we do have a way to make Win32-using programs work with just a relink, how about this transition scheme: - Add the previously suggested CYGWIN option for syncing the Win32 working directory, with two settings: on and off. Default to on for the moment. That would allow people like Daniel Colascione to switch it off if they don't care about the resulting failures in cygutils and elsewhere. - Implement the -lsynccwd scheme. - Notify maintainers about the rebuild that's necessary if their packages use Win32 APIs. Rebuild cygutils, git, and tcltk as soon as possible. - In a few months, switch the default to not sync, and hence allow working directories to be deleted., and which point. Affected programs that haven't been rebuilt could still be made to work by switching the option back on. Andy -- 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: ssh access violation [was: ssh simply prints Aborted]
Forwarding some messages from Gonzalo that the list is rejecting because of his company's disclaimer. More reports are coming with this problem, and they are asking Gonzalo if he found a solution. There is an Access Violation C005 exception that reminds me of the problems with programs produced with gcc 4.5 and its shared libgcc. [Fwd: RE: ssh simply prints Aborted] I just remembered this is Unix (almost)... So I did a strace on the process and realized I am getting a C005 exception (Access Violation). This is consistent for every run. Does this help in diagnosing the problem? $ strace /bin/ssh 5 5 [main] ssh 3288 open_shared: name shared.5, n 5, shared 0x60FB (wanted 0x60FB), h 0x780 25142519 [main] ssh 3288 heap_init: heap base 0x4B, heap top 0x4B 16424161 [main] ssh 3288 open_shared: name S-1-5-21-790525478-1364589140-1801674531-4836.1, n 1, shared 0x60FC (wanted 0x60FC), h 0x77C 30727233 [main] ssh 3288 user_info::create: opening user shared for 'S-1-5-21-790525478-1364589140-1801674531-4836' at 0x60FC 25359768 [main] ssh 3288 user_info::create: user shared version 6112AFB3 1549 11317 [main] ssh 3288 dll_crt0_0: finished dll_crt0_0 initialization 1303 12620 [main] ssh 3288 _cygtls::remove: wait 0x 1223 13843 [main] ssh 3288 _cygtls::remove: removed 0x22CE64 element 0 1265 15108 [main] ssh 3288 _cygtls::remove: wait 0x 1223 16331 [main] ssh 3288 _cygtls::remove: removed 0x22CE64 element 0 1494 17825 [main] ssh 3288 _cygtls::remove: wait 0x 1725 19550 [main] ssh 3288 _cygtls::remove: removed 0x22CE64 element 0 1686 21236 [main] ssh 3288 _cygtls::remove: wait 0x 1214 22450 [main] ssh 3288 _cygtls::remove: removed 0x22CE64 element 0 1434 23884 [sig] ssh 3288 wait_sig: entering ReadFile loop, my_readsig 0x754, my_sendsig 0x750 --- Process 3288, exception C005 at 6110B34F [Fwd: RE: ssh simply prints Aborted] I am a gdb noob... Does this help? (gdb) r Starting program: /bin/ssh [New thread 3772.0x78c] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 3772.0x1554] (no debugging symbols found) Program exited with code 0305. -- René Berber -- 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
1.7.7: Cannot unmount certain user bind mounts
A user mount whose only non-default option is bind cannot be unmounted if its target is a system mount; please see the end of this email for a test case. It looks to me as if the MOUNT_SYSTEM bit is copied from the bind target by mount() in winsup/cygwin/mount.cc. Perhaps the fix would be to preserve the value of the MOUNT_SYSTEM bit in the options of the bind mount, even when copying other options from the bind target. (Or perhaps, because this is mount() and not mount_info::from_fstab_line(), one could just clear MOUNT_SYSTEM unconditionally? Not sure.) The test case starts with various bits of information about the test environment, then a failure to unmount /bbb, and then two ways to avoid such failure: mounting /ddd with another non-default option (text) (probably this prevents copying of mount options from the bind target), and targeting /fff at another user mount (/eee) (so that when mount options are copied, the copied value of MOUNT_SYSTEM is 0): bu...@aeolus-w764c17 ~ $ uname -a CYGWIN_NT-6.1-WOW64 aeolus-w764c17 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin bu...@aeolus-w764c17 ~ $ cat /etc/fstab # For a description of the file format, see the Users Guide # http://cygwin.com/cygwin-ug-net/using.html#mount-table # This is default anyway: # none /cygdrive cygdrive binary,posix=0,user 0 0 none / cygdrive binary,posix=0,user 0 0 bu...@aeolus-w764c17 ~ $ mount -m none / cygdrive binary,posix=0,user 0 0 bu...@aeolus-w764c17 ~ $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /c type ntfs (binary,posix=0,user,noumount,auto) bu...@aeolus-w764c17 ~ $ mkdir /aaa /bbb /ccc /ddd /eee /fff bu...@aeolus-w764c17 ~ $ mount -o bind /aaa /bbb bu...@aeolus-w764c17 ~ $ umount /bbb umount: /bbb: Operation not permitted bu...@aeolus-w764c17 ~ $ mount -o bind,text /ccc /ddd bu...@aeolus-w764c17 ~ $ umount /ddd bu...@aeolus-w764c17 ~ $ mount c:/ /eee bu...@aeolus-w764c17 ~ $ mount -o bind /eee /fff bu...@aeolus-w764c17 ~ $ umount /fff bu...@aeolus-w764c17 ~ $ -- 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: ssh access violation [was: ssh simply prints Aborted]
One more forwarded message, before this we had found that we are both running Cygwin dll 1.7.7, where the access violation occurs, but the difference is that I have some old libraries (which setup.exe failed to install): cygcrypto, cygz, cyggcc_s, and cygssp. [Fwd: RE: ssh simply prints Aborted] (gdb) info shared FromTo Syms Read Shared Object Library 0x7c901000 0x7c9b1eb8 Yes /cygdrive/c/WINDOWS/system32/ntdll.dll 0x7c801000 0x7c8f5c84 Yes /cygdrive/c/WINDOWS/system32/kernel32.dll 0x6ba41000 0x6bb6573c Yes /usr/bin/cygcrypto-0.9.8.dll 0x61001000 0x6130 Yes /usr/bin/cygwin1.dll 0x77dd1000 0x77e6aaf8 Yes /cygdrive/c/WINDOWS/system32/advapi32.dll 0x77e71000 0x77f01488 Yes /cygdrive/c/WINDOWS/system32/rpcrt4.dll 0x77fe1000 0x77ff0888 Yes /cygdrive/c/WINDOWS/system32/secur32.dll 0x692c1000 0x692d7480 Yes /usr/bin/cygz.dll 0x67f01000 0x67f0f650 Yes /usr/bin/cyggcc_s-1.dll 0x67281000 0x67288158 Yes /usr/bin/cygssp-0.dll 0x60081000 0x600967d4 Yes /cygdrive/c/WINDOWS/system32/QIPCAP.dll -- René Berber -- 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
Setup.exe bug: leaving .new files uninstalled
Hi,
I've changed setup.exe just about every time it says there is a new
version, so I usually run the latest.
Today I found that some of my programs and libraries are not the latest
I thought I installed, and the following shows the problem:
$ for f in `ls /usr/bin/*.new`; do
ls -al $f ${f%.new}
done
-rwxr-xr-x 1 rb None 459K 2008-11-29 10:10 /usr/bin/bash.exe*
-rwxr-xr-x 1 rb root 460K 2010-08-13 11:58 /usr/bin/bash.exe.new*
-rwxr-xr-x 1 rb root 1.2M 2010-03-24 09:32 /usr/bin/cygcrypto-0.9.8.dll*
-rwxr-xr-x 1 rb root 1.2M 2010-06-23 03:56 /usr/bin/cygcrypto-0.9.8.dll.new*
-rwxr-xr-x 1 rb root 44K 2009-09-28 21:17 /usr/bin/cyggcc_s-1.dll*
-rwxr-xr-x 1 rb root 46K 2009-12-11 02:23 /usr/bin/cyggcc_s-1.dll.new*
-rwxr-xr-x 1 rb None 31K 2008-12-31 18:17 /usr/bin/cygintl-8.dll*
-rwxr-xr-x 1 rb root 31K 2009-04-02 23:04 /usr/bin/cygintl-8.dll.new*
-rwxr-xr-x 1 rb None 155K 2008-11-29 08:30 /usr/bin/cygreadline6.dll*
-rwxr-xr-x 1 rb root 155K 2009-06-23 07:25 /usr/bin/cygreadline6.dll.new*
-rwxr-xr-x 1 rb root 8.1K 2009-09-28 21:18 /usr/bin/cygssp-0.dll*
-rwxr-xr-x 1 rb root 11K 2009-12-11 02:24 /usr/bin/cygssp-0.dll.new*
-rwxr-xr-x 1 rb root 2.6M 2010-08-31 03:00 /usr/bin/cygwin1.dll*
-rwxr-xr-x 1 rb root 2.5M 2010-04-03 03:29 /usr/bin/cygwin1.dll.new*
-rwxr-xr-x 1 rb None 64K 2009-03-01 19:34 /usr/bin/cygz.dll*
-rwxr-xr-x 1 rb root 77K 2010-08-01 16:04 /usr/bin/cygz.dll.new*
-rwxr-xr-x 1 rb None 55K 2009-04-24 02:38 /usr/bin/libW11.dll*
-rwxr-xr-x 1 rb root 55K 2009-04-28 00:52 /usr/bin/libW11.dll.new*
-rwxr-xr-x 1 rb None 185K 2009-04-24 02:38 /usr/bin/rxvt.exe*
-rwxr-xr-x 1 rb root 185K 2009-04-28 00:52 /usr/bin/rxvt.exe.new*
-rwxr-xr-x 1 rb root 336K 2010-08-23 09:23 /usr/bin/ssh.exe*
-rwxr-xr-x 1 rb root 340K 2010-04-16 04:01 /usr/bin/ssh.exe.new*
root is just an alias in /etc/group for Administrators.
The .new files are not even consistent, not always the .new is the
latest version, as can be seen by the dates, for instance:
$ /usr/bin/bash.exe --version
GNU bash, version 3.2.48(21)-release (i686-pc-cygwin)
$ /usr/bin/bash.exe.new --version
GNU bash, version 3.2.51(24)-release (i686-pc-cygwin)
$ /usr/bin/ssh.exe -V
OpenSSH_5.6p1, OpenSSL 0.9.8n 24 Mar 2010
$ /usr/bin/ssh.exe.new -V
OpenSSH_5.5p1, OpenSSL 0.9.8n 24 Mar 2010
Has this bug been reported? Has it been corrected?
I seem to remember there was something at least similar reported, but
since some of those files are recent it looks like the error, if it was
the same, is still present.
On my end I guess I'll have to clean up the mess myself.
--
René Berber
--
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: Inability to delete *or rename* CWD of any program driving me nuts
On Fri, Sep 03, 2010 at 09:22:40AM -0700, Daniel Colascione wrote: On 9/3/10 12:45 AM, Corinna Vinschen wrote: If you read the announcement and followed the discussions on this list, you know why we had to do it. If it helps to share the pain, I don't like it either. Not the faintest. Of course I have, and I understand the workaround. What I don't understand is why the pipefs technique (for which you had working code, IIRC) wasn't used in the end. Was it the difficulty of changing cygtools to use the new interface? The additional interface complexity? Personally, I'd argue both are worth it. We're already using the pipefs technique. We just aren't making it the default. Since you are subscribed to cygwin-developers, the time to speak up was when this was discussed there rather than trying to rehash the discussion here. cgf -- 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: simulating console input
On 3 September 2010 10:01, Peter Münster wrote: On Fri, Sep 03 2010, Andy Koppe wrote: I've written a utility called 'conin' that translates pty input to console events. Perhaps that'll do the job. See here: http://groups.google.com/group/mintty-discuss/browse_thread/thread/1f9cf480117b8a0b Great, it works! It's as easy as echo y | conin DosProgram :) It works also very well with conin net use ... Good. Glad it's found some use. IMHO, this program should be mentioned here: http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console I'd probably need to get it into proper shape first and offer it as a Cygwin package. Andy -- 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: Network drives ssh access
--On Tuesday, August 24, 2010 1:35 PM -0700 Quanah Gibson-Mount wrote: --On Tuesday, August 24, 2010 1:19 PM -0400 Larry Hall (Cygwin) wrote: A missing password is likely your problem, since that's at the heart of your original problem really. But I actually wasn't thinking of this option as the solution to your problem when I pointed you at the FAQ. Running a service as the user you'll log in as is really just a workaround. I was thinking more of: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3 Using the passwd -R bit did not change the behavior. I still am unable to access the network share when logging in via SSH, but it works just fine when starting cygwin locally. I will note that the network share (CIFS) uses a different username/password than my local user/password on the windows box (That, unfortunately, is not under my control). However, I set up the share using net use \\IP\share /savecreds, and that does mount the drive to Windows at least every time without prompting, and Cygwin locally is able to use it. It is only an issue with the SSH connection. The CIFS mount now uses the same username/password as the windows user. I have used passwd -R to store the user's password in the registry. The drive again shows up when launching cygwin manually, and it still fails to show up when I use ssh to connect. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- 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: setup.exe version 2.721 crashes when performing a reinstall
Accidentially I hit thread http://cygwin.com/ml/cygwin/2010-09/msg00064.html because I saw the very same messages INVALID PACKAGE in my logfiles. There was also a length mismatch as mentioned in the thread above. After removing the gcc4 directory and downloading it again setup.exe no longer crashes (neither on Windows 7 nor on WinXP). KJ Am 20:59, schrieb KJ: When I try to use reinstall the setup.exe crashes on Windows XP as well as on Windows 7. The report below is from a crash on Windows 7. Has someone else experienced the same problem? TIA KJ Version=1 EventType=APPCRASH EventTime=129279109701574905 ReportType=2 Consent=1 ReportIdentifier=9038edba-b69d-11df-80fc-0023ae583e0a IntegratorReportIdentifier=9038edb9-b69d-11df-80fc-0023ae583e0a WOW64=1 Response.type=4 Sig[0].Name=Anwendungsname Sig[0].Value=setup.exe_unknown Sig[1].Name=Anwendungsversion Sig[1].Value=0.0.0.0 Sig[2].Name=Anwendungszeitstempel Sig[2].Value=4c77e78c Sig[3].Name=Fehlermodulname Sig[3].Value=StackHash_0a9e Sig[4].Name=Fehlermodulversion Sig[4].Value=0.0.0.0 Sig[5].Name=Fehlermodulzeitstempel Sig[5].Value= Sig[6].Name=Ausnahmecode Sig[6].Value=c005 Sig[7].Name=Ausnahmeoffset Sig[7].Value=ff7e5263 DynamicSig[1].Name=Betriebsystemversion DynamicSig[1].Value=6.1.7600.2.0.0.256.4 DynamicSig[2].Name=Gebietsschema-ID DynamicSig[2].Value=1031 DynamicSig[22].Name=Zusatzinformation 1 DynamicSig[22].Value=0a9e DynamicSig[23].Name=Zusatzinformation 2 DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789 DynamicSig[24].Name=Zusatzinformation 3 DynamicSig[24].Value=0a9e DynamicSig[25].Name=Zusatzinformation 4 DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789 UI[2]=E:\Downloads\CygInstall\setup.exe UI[3]=setup.exe funktioniert nicht mehr UI[4]=Windows kann online nach einer Lösung für das Problem suchen. UI[5]=Online nach einer Lösung suchen und das Programm schließen UI[6]=Später online nach einer Lösung suchen und das Programm schließen UI[7]=Programm schließen LoadedModule[0]=E:\Downloads\CygInstall\setup.exe LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll LoadedModule[2]=C:\Windows\syswow64\kernel32.dll LoadedModule[3]=C:\Windows\syswow64\KERNELBASE.dll LoadedModule[4]=C:\Windows\syswow64\ADVAPI32.DLL LoadedModule[5]=C:\Windows\syswow64\msvcrt.dll LoadedModule[6]=C:\Windows\SysWOW64\sechost.dll LoadedModule[7]=C:\Windows\syswow64\RPCRT4.dll LoadedModule[8]=C:\Windows\syswow64\SspiCli.dll LoadedModule[9]=C:\Windows\syswow64\CRYPTBASE.dll LoadedModule[10]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.DLL LoadedModule[11]=C:\Windows\syswow64\GDI32.dll LoadedModule[12]=C:\Windows\syswow64\USER32.dll LoadedModule[13]=C:\Windows\syswow64\LPK.dll LoadedModule[14]=C:\Windows\syswow64\USP10.dll LoadedModule[15]=C:\Windows\syswow64\SHLWAPI.dll LoadedModule[16]=C:\Windows\syswow64\OLE32.dll LoadedModule[17]=C:\Windows\syswow64\SHELL32.DLL LoadedModule[18]=C:\Windows\system32\WSOCK32.DLL LoadedModule[19]=C:\Windows\syswow64\WS2_32.dll LoadedModule[20]=C:\Windows\syswow64\NSI.dll LoadedModule[21]=C:\Windows\system32\apphelp.dll LoadedModule[22]=C:\Windows\AppPatch\AcGenral.DLL LoadedModule[23]=C:\Windows\system32\UxTheme.dll LoadedModule[24]=C:\Windows\system32\WINMM.dll LoadedModule[25]=C:\Windows\system32\samcli.dll LoadedModule[26]=C:\Windows\syswow64\OLEAUT32.dll LoadedModule[27]=C:\Windows\system32\MSACM32.dll LoadedModule[28]=C:\Windows\system32\VERSION.dll LoadedModule[29]=C:\Windows\system32\sfc.dll LoadedModule[30]=C:\Windows\system32\sfc_os.DLL LoadedModule[31]=C:\Windows\system32\USERENV.dll LoadedModule[32]=C:\Windows\system32\profapi.dll LoadedModule[33]=C:\Windows\system32\dwmapi.dll LoadedModule[34]=C:\Windows\syswow64\SETUPAPI.dll LoadedModule[35]=C:\Windows\syswow64\CFGMGR32.dll LoadedModule[36]=C:\Windows\syswow64\DEVOBJ.dll LoadedModule[37]=C:\Windows\syswow64\urlmon.dll LoadedModule[38]=C:\Windows\syswow64\CRYPT32.dll LoadedModule[39]=C:\Windows\syswow64\MSASN1.dll LoadedModule[40]=C:\Windows\syswow64\iertutil.dll LoadedModule[41]=C:\Windows\system32\MPR.dll LoadedModule[42]=C:\Windows\system32\IMM32.DLL LoadedModule[43]=C:\Windows\syswow64\MSCTF.dll LoadedModule[44]=C:\Windows\syswow64\CLBCatQ.DLL LoadedModule[45]=C:\Windows\syswow64\wininet.dll LoadedModule[46]=C:\Windows\syswow64\Normaliz.dll LoadedModule[47]=C:\Windows\system32\dnsapi.DLL LoadedModule[48]=C:\Windows\system32\iphlpapi.DLL LoadedModule[49]=C:\Windows\system32\WINNSI.DLL LoadedModule[50]=C:\Windows\system32\RASAPI32.dll LoadedModule[51]=C:\Windows\system32\rasman.dll LoadedModule[52]=C:\Windows\system32\rtutils.dll LoadedModule[53]=C:\Windows\system32\sensapi.dll LoadedModule[54]=C:\Windows\system32\peerdist.dll LoadedModule[55]=C:\Windows\system32\AUTHZ.dll LoadedModule[56]=C:\Windows\system32\NLAapi.dll LoadedModule[57]=C:\Windows\System32\mswsock.dll
Re: Setup.exe bug: leaving .new files uninstalled
René Berber wrote: I seem to remember there was something at least similar reported, but since some of those files are recent it looks like the error, if it was the same, is still present. Additional info... The old bug was Setup 2.693 unable to replace files through reboot. Currently I have version 2.721, but as I said, just by looking at the file's date this has been happening with several versions (setup changed at least twice last month). I don't have HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations on my registry, and FileRenameOperations is empty. None of the other suspect causes named on the thread about the old bug applies (i.e. no network drives, access to the registry is as a member of Administrators group, no dynamic volume.) -- René Berber -- 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: Network drives ssh access
--On Friday, September 03, 2010 12:28 PM -0700 Quanah Gibson-Mount wrote: --On Tuesday, August 24, 2010 1:35 PM -0700 Quanah Gibson-Mount wrote: The CIFS mount now uses the same username/password as the windows user. I have used passwd -R to store the user's password in the registry. The drive again shows up when launching cygwin manually, and it still fails to show up when I use ssh to connect. $ net use New connections will be remembered. Status Local RemoteNetwork --- Unavailable Z:\\10.137.242.250\Zbuild3 Microsoft Windows Network The command completed successfully. $ net use Z: '\\10.137.242.250\Zbuild3' The command completed successfully. $ net use New connections will be remembered. Status Local RemoteNetwork --- OK Z:\\10.137.242.250\Zbuild3 Microsoft Windows Network The command completed successfully. So, mounting it works ok if I do it manually via ssh. But why isn't it simply showing up when it's already mounted on the system, and the credentials have been stored via passwd -R? It was also mounted using /savecred --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- 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: problem with PATH set by libtool for uninstalled pixman library
On 7/29/2010 4:20 AM, Charles Wilson wrote: On 7/28/2010 2:24 PM, Jon TURNEY wrote: I have a tinderbox which does daily builds of the X.Org stack for cygwin, and I've come across a something I don't understand with the way libtool is working when building the pixman library, and I hope someone can shed a bit of light. I think a patch to simply swap the order of these two assignments would be fine (e.g. do $dllsearchpath first, then make sure it gets pre-empted by $rpath). On *nix it wouldn't matter, since the two variables are DISTINCT vars. Can you give the most recent (libtool-2.2.11a-1) release a try, and let me know if it fixes your problem? -- 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
Updated: {libtool/libltdl7}-2.2.11a-1
GNU libtool is a generic library support script. Libtool hides the
complexity of using shared libraries behind a consistent, portable
interface.
This is a bugfix and feature enhancement update.
[[ compiled using gcc-4.3.4-3 ]]
CHANGES SINCE 2.2.7a-15
=
* Updated to latest git master version (2010-09-02,
0f052db3b89835904b95d8336b2491e7b8eef8f7)
* libtool script supports linking with .la files that contain
an '='-indicated sysroot
* Projects using libtool now support a new --with-sysroot=... option
* Largest cygwin patches have been merged upstream
* Remaining (old) patches:
+ allow runtime library flags (like -static-libgcc)
- Yaakov Selkowitz libtool: -{shared,static}-libgcc
http://www.cygwin.com/ml/cygwin/2009-08/msg00243.html
+ [cygwin|mingw] Create UAC manifest files (as modified)
* New patches:
+ Fix linking with -fstack-protector (Yaakov Selkowitz)
http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7330/focus=7341
+ Fix order of PATH manipulation in cwrapper (reported by Jon Turney)
http://cygwin.com/ml/cygwin/2010-07/msg00601.html
* Does not yet support LTO. There is an lto branch upstream, and it is
slated to be merged in to the release branch before 2.2.12 (due RSN)
I'll update again at that time.
Test results -- old tests:
=
All 122 tests passed
(2 tests were not run)
Test results -- new tests:
=
111 tests behaved as expected.
9 tests were skipped.
(no regressions from 2.2.7a-15)
--
Charles Wilson
volunteer libtool maintainer for cygwin
To update your installation, click on the Install Cygwin now link
on the http://cygwin.com/ web page. This downloads setup.exe to
your system. Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is
available starting at this URL.
