Re: Updated: guile-1.8.7
On Mon, Nov 22, 2010 at 11:10:39AM +0100, Jan Nieuwenhuizen wrote: I've updated the version of Guile to 1.8.7. This also includes the guile-devel packages. This is a new upstream release. For a full update of changes, see the file usr/share/doc/guile/NEWS in the guile-doc package. Cygwin-specific changes * New upstream release. * Add int scm_i_terminating export, thanks Yaakov. * Move to gub3: http://lilypond.org/gub . == I have installed guile 1.8.7, guile-doc 1.8.7, and libguile17 1.8.7, along with cygwin 1.7.7: $ cygcheck -c cygwin guile guile-doc libguile17 Cygwin Package Information Package VersionStatus cygwin 1.7.7-1OK guile1.8.7-1OK guile-doc1.8.7-1OK libguile17 1.8.7-1OK I have previously been able to install and start guile 1.8.2 without error, but when I attempt to start guile 1.8.7, it fails immediately with a Stack overflow error: $ guile -q --debug -- Backtrace: In unknown file: ?: 129* [#procedure #f ()] ?: 130* (let* ((file #)) (cond (# = #) (# = #))) ?: 131 [#procedure #f (full) /usr/share/guile/1.8/ice-9/debug.scm] ?: 132 [with-fluid* #fluid 7 #f #procedure #f ()] ?: 133* [#procedure #f ()] ?: 134* [load-file #primitive-procedure primitive-load ...] ?: 135* [save-module-excursion #procedure #f ()] ?: 136 (let (# #) (dynamic-wind # thunk #)) ?: 137 [dynamic-wind #procedure #f () #procedure #f () #procedure #f ()] ?: 138* [#procedure #f ()] ?: 139* [primitive-load /usr/share/guile/1.8/ice-9/debug.scm] In /usr/share/guile/1.8/ice-9/debug.scm: 22: 140* (define-module (ice-9 debug) :export ...) In unknown file: ?: 141* [copy-tree ... ?: 142* [apply #procedure #f args (# :export #)] ?: 143 [#procedure #f args (ice-9 debug) :export ...] ?: 144 (quasiquote (eval-case (# #) (else #))) ?: 145* [compile-define-module-args (# :export #)] ?: 146 ((letrec ((loop #)) loop) (quasiquote ((quote #))) (cdr args)) ?: 147* (letrec ((loop (lambda # #))) loop) ?: 148* (lambda (compiled-args args) (cond (# #) (# #) (# #) ...)) unnamed port: In expression (lambda (compiled-args args) (cond # # ...)): unnamed port: Stack overflow --- End of stack dump --- This error is repeatable (the same error messages with the same line numbers). The same error occurs if guile is provided no command-line options. I can un-install version 1.8.7, install version 1.8.2, and start guile without error. Please let me know if there is some information that I can provide that would help to diagnose the source of this problem. Here are sha1sums of the files that I have downloaded and installed: $ sha1sum.exe guile-1.8.7-1.tar.bz2 ee5cdc729998bfd7c8aa93c9e53467d28c77153b *guile-1.8.7-1.tar.bz2 $ sha1sum.exe libguile17-1.8.7-1.tar.bz2 cb35fa72ad8fe46a27abfc2bd3d38f731cb127e5 *libguile17-1.8.7-1.tar.bz2 $ sha1sum.exe guile-doc-1.8.7-1.tar.bz2 2e42accc2103f7ee83808b91319bf43611004a36 *guile-doc-1.8.7-1.tar.bz2 $ sha1sum cygwin-1.7.7-1.tar.bz2 61d32c981e6aa1d19b8586d1f9f6c19d87b06bf2 *cygwin-1.7.7-1.tar.bz2 -- 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: Updated: guile-1.8.7
On Tue, Nov 23, 2010 at 09:06:44PM -0500, Mark Harig wrote: On Mon, Nov 22, 2010 at 11:10:39AM +0100, Jan Nieuwenhuizen wrote: I've updated the version of Guile to 1.8.7. This also includes the guile-devel packages. This is a new upstream release. For a full update of changes, see the file usr/share/doc/guile/NEWS in the guile-doc package. Cygwin-specific changes * New upstream release. * Add int scm_i_terminating export, thanks Yaakov. * Move to gub3: http://lilypond.org/gub . == I have installed guile 1.8.7, guile-doc 1.8.7, and libguile17 1.8.7, along with cygwin 1.7.7: $ cygcheck -c cygwin guile guile-doc libguile17 Cygwin Package Information Package VersionStatus cygwin 1.7.7-1OK guile1.8.7-1OK guile-doc1.8.7-1OK libguile17 1.8.7-1OK I have previously been able to install and start guile 1.8.2 without error, but when I attempt to start guile 1.8.7, it fails immediately with a Stack overflow error: 1. Here is a check of the other packages that guile requires at run-time: $ cygcheck -c crypt gmp libltdl3 Cygwin Package Information Package VersionStatus crypt1.1-1 OK gmp 4.3.1-3OK libltdl3 1.5.27a-1 OK $ cygcheck -c libintl2 libintl3 libintl8 Cygwin Package Information Package VersionStatus libintl2 0.12.1-3 OK libintl3 0.14.5-1 OK libintl8 0.17-11OK 2. Another problem is that guile-doc 1.8.7, unlike guile-doc 1.8.2, does not include the 'info' documentation files: $ cygcheck -l guile-doc /usr/share/doc/guile/GUILE-VERSION /usr/share/doc/guile/LIBGUILEREADLINE-VERSION /usr/share/doc/guile/PROGRAM /usr/share/doc/guile/ChangeLog-2008 /usr/share/doc/guile/NEWS /usr/share/doc/guile/LICENSE /usr/share/doc/guile/ChangeLog /usr/share/doc/guile/ChangeLog-gh /usr/share/doc/guile/COPYING.LESSER /usr/share/doc/guile/THANKS /usr/share/doc/guile/ChangeLog-2000 /usr/share/doc/guile/README /usr/share/doc/guile/AUTHORS /usr/share/doc/guile/HACKING /usr/share/doc/guile/ChangeLog-scm /usr/share/doc/guile/INSTALL /usr/share/doc/guile/ABOUT-NLS /usr/share/doc/guile/ChangeLog-1996-1999 /usr/share/doc/guile/ChangeLog-threads -- 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
cygwin-1.7/clisp-2.48-1: Cannot initialize clisp with full linking set
Thank you for providing clisp version 2.48. I am unable to start clisp if I specify the full linking set: $ clisp -Kfull /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries: svm.dll: cannot open shared object file: No such file or directory $ cygcheck -l clisp | grep svm.dll /usr/lib/clisp-2.48/full/svm.dll $ file /usr/lib/clisp-2.48/full/svm.dll /usr/lib/clisp-2.48/full/svm.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit $ md5sum /usr/lib/clisp-2.48/full/svm.dll 3f0dfd94d955bfb567581c853ed32587 */usr/lib/clisp-2.48/full/svm.dll $ cygcheck -c clisp Cygwin Package Information Package VersionStatus clisp2.48-1 OK /usr/lib/clisp-2.48/full/svm.dll was installed with the executable permission turned off. Turning on the executable permission had no effect: $ chmod +x /usr/lib/clisp-2.48/full/svm.dll $ ls -l /usr/lib/clisp-2.48/full/svm.dll -rwxr-xr-x 1 username root 99K Aug 1 16:02 /usr/lib/clisp-2.48/full/svm.dll* $ clisp -Kfull /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries: svm.dll: cannot open shared object file: No such file or directory Also, the following (possibly related?) problem exists: $ cd /usr/lib/clisp-2.48/full $ clisp -Kfull /usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries: cygdb-4.6.dll: cannot open shared object file: No such file or directory There is no version cygdb-4.6.dll installed, and, as far as I can tell, there is no version cygdb-4.6.dll available yet. If the base linking set is specified, then clisp starts and exits without error: $ clisp -Kbase -q [1] (exit) $ Can anyone suggest any troubleshooting steps to take to resolve this problem, or are these problems above caused by errors in the Cygwin packaging of clisp? -- 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
Questions about setting the CYGWIN env. variable's 'error_start'
Mon, 6 Jul 2009 11:21:14 -0400 , Christopher Faylor wrote: For the curious, I debugged it by doing this: set CYWGIN=error_start:gdb When gdb popped up, the stack trace led me straight to the problem. Thanks for the reminder. Here is the documentation for the 'error_start' option: http://cygwin.com/cygwin-ug-net/using-cygwinenv.html or, http://cygwin.com/1.7/cygwin-ug-net/using-cygwinenv.html |error_start:Win32filepath| - if set, runs |Win32filepath| when cygwin encounters a fatal error, which is useful for debugging. |Win32filepath| is usually set to the path to *gdb* or *dumper*, for example |C:\cygwin\bin\gdb.exe|. There is no default set. Is there a canonical or recommended, robust method that should be used for setting 'error_start'? It appears that your method assumes the value of PATH is set appropriately. Is it recommended that users define the environment variable 'Win32filepath' to have the value of the Windows location of the desired debugger and, if so, can this be changed dynamically? (That is, if a user changes 'Win32filepath' at, say, a shell prompt, would this be picked up by 'error_start'?) And has the new 'insight' GUI included with 'gdb' been tested to work as a value for 'error_start'? -- 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: Questions about setting the CYGWIN env. variable's 'error_start'
Thanks for the reminder. Here is the documentation for the 'error_start' option: http://cygwin.com/cygwin-ug-net/using-cygwinenv.html or, http://cygwin.com/1.7/cygwin-ug-net/using-cygwinenv.html |error_start:Win32filepath| - if set, runs |Win32filepath| when cygwin encounters a fatal error, which is useful for debugging. |Win32filepath| is usually set to the path to *gdb* or *dumper*, for example |C:\cygwin\bin\gdb.exe|. There is no default set. Is there a canonical or recommended, robust method that should be used for setting 'error_start'? It appears that your method assumes the value of PATH is set appropriately. Is it recommended that users define the environment variable 'Win32filepath' to have the value of the Windows location of the desired debugger and, if so, can this be changed dynamically? (That is, if a user changes 'Win32filepath' at, say, a shell prompt, would this be picked up by 'error_start'?) And has the new 'insight' GUI included with 'gdb' been tested to work as a value for 'error_start'? To follow up, the behavior of Cygwin (bash?) is different depending on whether cygwin 1.5 or cygwin 1.7 is used. The environment variable 'Win32filepath' is null for some reason in Cygwin 1.5 (the value has been set via the Environment Variables applet in the Control Panel's System applet). 1. Cygwin 1.5: bash --norc --noprofile bash-3.2$ echo $CYGWIN tty error_start:Win32filepath bash-3.2$ echo $Win32filepath [no value printed] bash-3.2$ /bin/cygcheck -c bash cygwin Cygwin Package Information Package Version Status bash3.2.49-22OK cygwin1.5.25-15 OK 2. Cygwin 1.7: bash --norc --noprofile bash-3.2$ echo $CYGWIN tty error_start:Win32filepath bash-3.2$ echo $Win32filepath c:\cygwin-1.7\bin\gdb.exe bash-3.2$ /bin/cygcheck -c bash cygwin Cygwin Package Information Package Version Status bash3.2.49-23OK cygwin1.7.0-50 OK -- 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: Stuck trying to reinstall Emacs 23.0.92 and setup dying each time
KARR, DAVID wrote: I had set up Cygwin yesterday with the experimental Emacs 23.0.92. I had done other updates after that, forgetting the fact that since I'm using an experimental package, I have to set the Emacs-related pages to Keep. I'm now in a state where I have the 23.0.92 executable, but with /usr/share/emacs/21.2. So, now I'm trying to run setup again to reinstall 23.0.92, or uninstall it, or anything. No matter what I do, setup dies hard, requiring a forced kill from task manager. What can I do to clean up from this situation? Have you inspected the 'setup.log' and 'setup.log.full' files in /var/log/? They might provide some clues about where setup is having problems. If those files do not make it clear what you need to do, then the experts on 'setup' might be able to help with the information those files provide. Also, which version of emacs does cygwin think is installed? $ cygcheck -c emacs emacs-el -- 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: Stuck trying to reinstall Emacs 23.0.92 and setup dying each time
Wed, 1 Jul 2009 15:37:09 -0700 David Karr wrote: Ok, so that shows that emacs-el.lst.gz was corrupted. I deleted it, then reran setup. I clicked Exp, then View, then scrolled down to the three emacs* lines and set them all to Reinstall (the Current column says 23.0.92-2) and clicked Next. It chugged for a bit, last displaying Uninstalling emacs-el, then reported setup.exe has encountered After dismissing the dialog, I looked at /etc/setup again, and the corrupted emacs-el.lst.gz was there again. I also checked to see whether any other *.lst.gz files were corrupted, and there were none. This message might be of some help to you: http://sourceware.org/ml/cygwin/2008-06/msg00563.html In particular, you could try downloading: http://rapidshare.com/files/98717404/setup.exe Perhaps one of the setup.exe experts could remark on the advisability of trying this. I used it with success once in the past when my cygwin 1.5 installation became corrupted. -- 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 displaying ASCII table in mintty
With this configuration, the upper 128 entries to the ASCII table are displayed as follows (the #'s are replacements for the gray box character that is displayed): That's because because bytes from 0x80 to 0xFF by themselves are invalid in UTF-8. Those codepoints need to be encoded as two-byte sequences. I'd suspect /bin/ascii isn't designed for that. OK. From what you have written, it appears that the defect is in /usr/bin/ascii (cygutils) in that it does not support UTF-8. Either that will need to be fixed or the documentation for the tool could list/describe the problem so that other users are told that it is known. In addition, many entries are displayed in the wrong location (some rows are out of order). That's because some of the C1 control characters are interpreted specially, in particular CSI and OSC. It's the same if you try it in xterm. You can get most of the printable characters in the C1 range by switching to Windows codepage 1252. (Well, you could anyway if it wasn't for a rather bad bug in mintty-0.4.0 and 0.4.1 that means that ISO-8859-1 is used no matter your codepage setting. That's fixed on the 0.4 SVN branch.) OK. Users can display the upper 128 entries in 'rxvt' so there is a work-around in a Cygwin environment. (In 'rxvt', LC_CTYPE should not be set to UTF-8. AFAIK, UTF-8 is not supported in cygwin's rxvt.) -- 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 displaying ASCII table in mintty
Fri, 26 Jun 2009 10:50:45 -0400 Mark J. Reed wrote: Is is possible to display the upper 128 entries in the ASCII table in mintty using the 'cygutils' application 'ascii'? The ASCII table doesn't have an upper 128 entries. Only codes 0 through 127 decimal are defined by ASCII. Once you hit 128 you're not in ASCII anymore, and what you *are* in depends entirely on what code page you're using. 128 through 159 are control characters in Unicode and Latin-1, but printable characters in Windows 1252. 160 through 255 are the same in Windows 1252, Latin-1, and Unicode, but defined differently in the other ISO-8859 and ISO-2022 character sets and Windows code pages. If you're using UTF-8 (a particular way of representing Unicode characters, which are defined as numbers, as concrete bits and bytes), then only characters 0 through 127 can be expressed in one byte. Characters from 128 to 2047 take two bytes; the rest of the BMP (2048 through 65536) three bytes per character, and the rest of Unicode four bytes per character. So if you just send the byte with decimal value 128, not preceded by the start of a UTF-8 sequence, to a UTF-8 terminal, the terminal will reject it as invalid, or display gobbledygook, depending on its error handling design. Thank you for the explanation. I see from the manual page for 'ascii' provided at http://www.kernel.org/pub/linux/docs/manpages/ that the ASCII table is as you described (that is, 128 entries only). Do you have any recommendations about what the utility program /usr/bin/ascii (in the package 'cygutils') should do? Should it not provide a display of the values above 128 because they are not part of the ASCII table? Does it make sense to provide options that handle the values above 128 under the various conditions described above? -- 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
Cygwin 1.7 setup-1.7.exe minor display error
Steps to reproduce the error: 1. Start setup-1.7.exe. Click on 'Next ' button until the 'Select Packages' dialog window is displayed. 2. By default, setup displays the Select Packages window maximized. Click on the 'Restore Down' button in the right-hand corner to reduce the size of the window. 3. Note that to the right of the 'Search' box, the 'Clear' button is not displayed (or, displayed only partially), as follows: Search |_|[ o Keep o Prev o Curr o Exp [View] Category It should be displayed as follows: Search |_|[Clear] o Keep o Prev o Curr o Exp [View] Category Maximizing and restoring the window does not fix the display problem. I have restarted setup-1.7.exe several times (more than three) to confirm that the problem can be reproduced. -- 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 mintty-0.4.1-1 and orpie
(TERM=xterm by default for me. I have no idea where that comes from.) This is documented in the manual page for 'mintty': TERM variable The TERM variable for the child process is set to xterm, so that pro‐ grams that pay attention to it expect xterm keycodes and output xterm‐ compatible control sequences. There is no documented way in mintty to change the TERM environment before the shell is started. It may turn out to be necessary (some day?) for mintty to provide some method for the shell to know whether it is running in a mintty terminal or an xterm terminal. -- 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 mintty-0.4.1-1 and orpie
Thu, 25 Jun 2009 20:25:09 +0100 Andy Kope wrote: There is no documented way in mintty to change the TERM environment before the shell is started. There's a bit in the TIPS section of the manual on how to set any environment variable using the shell's -c option, e.g.: mintty sh -c TERM=xterm-256color emacs OK. When I wrote my comments, I had been thinking about the shell (which ever one the user chooses) itself and had not thought of using 'sh -c' on it. The following works: mintty sh -c FOO=baz /bin/bash --norc --noprofile bash-3.2$ echo $FOO baz However, with this approach there is this side effect that users should probably be aware of: bash-3.2$ echo $SHLVL 2 From the 0.4.0 release announcement: - MinTTY now has its own identity, instead of pretending to be an old xterm. The ^E answerback string is mintty, the ^[[c primary device attribute command reports a vt100, and the ^[[c secondary DA command reports terminal type 77 (ASCII 'M') and version 400. The TERM variable remains set to xterm though, to avoid termcap/terminfo trouble I could not find this description in the manual page for mintty or in /usr/share/doc/Cygwin/mintty-0.4.1.README. I assume that you will add this information to the documentation when you want users to be able to make use of 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
Problem with displaying ASCII table in mintty
Is is possible to display the upper 128 entries in the ASCII table in mintty using the 'cygutils' application 'ascii'? Package versions: bash-3.2$ /usr/bin/cygcheck -c bash cygutils cygwin mintty Cygwin Package Information Package VersionStatus bash 3.2.49-22 OK cygutils 1.4.0-1OK cygwin 1.7.0-50 OK mintty 0.4.1-1OK bash-3.2$ /usr/bin/ascii --version /usr/bin/ascii is part of cygutils version 1.4.0 Prints nicely formatted table of the ascii character set I have attempted to use two configurations, but neither one displays the table without problems in mintty: Configuration 1: - mintty: Using the font's codepage set to UTF-8 bash-3.2$ /usr/bin/grep Codepage ~/.minttyrc Codepage=UTF-8 - bash: bash-3.2$ echo $TERM xterm bash-3.2$ echo \$LANG\ : \$LC_ALL\ : \$LC_CTYPE\ en_US.UTF-8 : en_US.UTF-8 : en_US.UTF-8 With this configuration, the upper 128 entries to the ASCII table are displayed as follows (the #'s are replacements for the gray box character that is displayed): bash-3.2$ /usr/bin/ascii 128 0x80 #160 0xa0 #192 0xc0 #224 0xe0 # ... 159 0x9f #191 0xbf #223 0xdf # 255 0xff # Configuration 2: - mintty: Using the font's codepage set to ISO-8859-1 bash-3.2$ /usr/bin/grep -i codepage ~/.minttyrc Codepage=ISO-8859-1:1998 (Latin-1, West Europe) - bash: bash-3.2$ echo \$LANG\ : \$LC_ALL\ : \$LC_CTYPE\ en_US.ISO-8859-1 : en_US.ISO-8859-1 : en_US.ISO-8859-1 With this second configuration, most of the upper 128 entries of the ASCII table are displayed, but many are missing. In addition, many entries are displayed in the wrong location (some rows are out of order). Note: I had mintty start bash with the '--norc' and '--noprofile' options. -- 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: Some questions about mintty
At the bash shell prompt while editing commands is one example, but it is also the case for me in text editors, vim or emacs, for example. From the Options menu, I set the cursor type to block and set the cursor color to a light color, say, yellow, and then moved the block cursor back over the text of a command at the shell prompt. Because the cursor-text color remained white, when it combined with the light block color, the text inside the cursor block disappeared. Could you attach your .minttyrc? Have you got any commands in your bash startup files that might be relevant here? And what's you PS1 setting? To simplify the problem, I eliminated the ~/.bashrc ~/.bash_profile initialization files: $ mintty -e /bin/bash --norc --noprofile Please find attached a simplified ~/.minttyrc file. I renamed my old file, started mintty, set the color options for foreground, background, and cursor, set the cursor type to 'block' and then accepted these changes to generate a new ~/.minttyrc file. PS1 is: [~]$ echo $PS1 [\W]\$ The behavior with the block cursor's text remains: The text is light inside the light block, making the character difficult to read. Using the solution that you provided (echoing an escape sequence to set the cursor text color) fixes the problem. Columns=80 Rows=36 Transparency=0 OpaqueWhenFocused=1 Scrollbar=1 ScrollbackLines=1 ConfirmExit=1 WindowShortcuts=1 EditShortcuts=1 ZoomShortcuts=1 BoldAsBright=0 AllowBlinking=0 CursorType=0 CursorBlinks=0 FontIsBold=0 FontHeight=14 FontCharset=0 FontQuality=1 BackspaceSendsDEL=1 EscapeSendsFS=0 AltSendsESC=0 ScrollMod=1 RightClickAction=0 CopyOnSelect=1 ClicksPlaceCursor=0 ClicksTargetApp=1 ClickTargetMod=1 BellType=1 BellIndication=2 Font=Lucida Sans Typewriter Codepage=UTF-8 Printer= ForegroundColour=0,0,0 BackgroundColour=255,255,255 CursorColour=255,255,0 -- 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: Some questions about mintty
3. When the color of the cursor is changed to a block, the text � can be read through the block, but it appears that the text is � always white. The background colour is used for text beneath the cursor, so if the cursor is visible infront of the background, the text beneath the cursor should be visible too. With the default white-on-black colours, you get black text inside a white cursor block. Is it a particular mode or program where you're seeing this problem? At the bash shell prompt while editing commands is one example, but it is also the case for me in text editors, vim or emacs, for example. From the Options menu, I set the cursor type to block and set the cursor color to a light color, say, yellow, and then moved the block cursor back over the text of a command at the shell prompt. Because the cursor-text color remained white, when it combined with the light block color, the text inside the cursor block disappeared. �Can the cursor's (reverse) text color be changed? Yes, through the xterm sequence for setting colours, where in a small extension the default colours are represented as colours 256 through 261: 256 - normal foreground 257 - bold foreground 258 - normal background 259 - bold background 260 - cursor background 261 - cursor foreground For example, this sets the cursor background colour (which is used for the text beneath it) to black: echo -e \e]4;260;#00\a Thank you. That works. I have added the following to ~/.bashrc: case $TERM in ... xterm) if [ $OS = Windows_NT ]; then # Set mintty's (block) cursor text color to black echo -e \e]4;260;#00\a ... else ... fi ... esac -- 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
Some questions about mintty
My installed packages: $ cygcheck -c cygwin mintty Cygwin Package Information Package VersionStatus cygwin 1.7.0-50 OK mintty 0.4.1-1OK 1. There is no description of the '-e' switch in mintty's manual page. Is it an execute-this-command option? Or, should the user be aware that it is specific to execute this shell? 2. There is a '-p / --position' option described in the manual page. Is there a corresponding option for the ~/.minttyrc initialization file? (If so, I could not find a description of it in the manual page for mintty or /usr/share/doc/Cygwin/mintty-0.4.1.README.) 3. When the color of the cursor is changed to a block, the text can be read through the block, but it appears that the text is always white. Can the cursor's (reverse) text color be changed? If a light color is chosen for the cursor block, then the white text within the block is difficult to read. The behavior of xterm in X is that the cursor text is inverted, that is, it is dark if the cursor block is light, and light if the cursor block is dark. 4. Is is possible to view italic fonts (in italicized form) in mintty? I selected Italic and Bold Italic entries from the 'Font Style' list, but could not get mintty to accept/acknowledge those selections. Thanks to the author(s) of mintty for providing 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
Cygwin 1.7: Dependency errors in Emacs installation
During the post-installation of emacs 23.0.92-10, the following error messages are written to /var/log/setup.log.full: Visited: 68 nodes out of 1460 while creating dependency order. Dependency order of packages: base-cygwin base-passwd cygwin libiconv2 libintl8 alternatives alternatives libgmp3 libintl3 texinfo _update-info-dir gawk tzcode coreutils terminfo0 libncurses8 libreadline6 bash ash libaspell15 aspell aspell-doc aspell-en findutils sed base-files libbz2_1 bzip2 libpopt0 cygutils groff gzip terminfo libncurses9 less man cygwin-doc libintl2 diffutils editrights xemacs-emacs-common emacs emacs-el libexpat1 libexpat1-devel expat gcc4-runtime libgcc1 libpcre0 grep ipc-utils libdb4.2 libgdbm4 libproj0 login openssl tcltk zlib0 zlib-devel zlib python Numeric rebase run rxvt tar termcap which 2009/06/21 11:19:21 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/emacs.sh /etc/postinstall/emacs.sh: line 9: /usr/bin/update-desktop-database: No such file or directory /etc/postinstall/emacs.sh: line 10: /usr/bin/update-mime-database: No such file or directory -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
Dave Korn wrote: However, now you've got rid of that, a quick re-run through setup.exe and set everything to reinstall on the chooser page should fix it. setup-1.7.exe is running pretty reliably now that I have stopped (but not removed) these two services via the Services app: LVCOMSer (Logitech Video COM Service) LVSvrLauncher (Launcher for Logitech Video Components) But I continue to see the following type of error (cut from a terminal session that occurred moments ago) when running various cygwin programs: $ man emacs 5 [main] sh 7444 C:\cygwin-1.7\bin\sh.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x6D, top 0x73, reserve_size 389120, allocsize 393216, page_const 4096 5 [main] sh 8212 C:\cygwin-1.7\bin\sh.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0x6D, top 0x73, reserve_size 389120, allocsize 393216, page_const 4096 3 [main] sh 9104 child_info::sync: wait failed, pid 7444, Win32 error 0 136 [main] sh 9104 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 40 [main] sh 9036 child_info::sync: wait failed, pid 8212, Win32 error 0 179 [main] sh 9036 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11 (FWIW, the 'max_memory.exe' program reports that over 1500 Mbytes are available.) Is there a general troubleshooting approach that can be recommended to cygwin users that can isolate defects in cygwin applications from defects that are caused by interaction with other ms-windows applications? For example, if windows is booted to Safe Mode or Safe Mode with Networking, can errors be reliably attributed to cygwin defects, and not to inter-application problems? -- 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
Some files are missing from cygwin-doc version 1.5-1
setup-1.7.exe installs the package 'cygwin-doc', version 1.5-1. This package includes /usr/share/info/cygwin.info. cygwin.info references two files, 'cygwin-ug-net.info' and 'cygwin-api.info', which are not included in 'cygwin-doc': $ cygcheck -c cygwin-doc Cygwin Package Information Package Version Status cygwin-doc1.5-1 OK $ cygcheck -l cygwin-doc | grep /usr/share/info/cygwin /usr/share/info/cygwin.info -- 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/
Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
When I ran setup-1.7.exe with the default set of packages
selected, the following error message was displayed:
running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c
/etc/postinstall/base-files-profile.sh
abnormal exit: exit code=-1073741819
'base-files-profile.sh' contains the following line:
/bin/mkdir -p `dirname ${fDest}`
'dirname' is /usr/bin/dirname. Does setup-1.7.exe set
PATH before running 'base-files-profile.sh'? If not,
then this would account for the error.
It is possible to rewrite the command without using
'dirname':
/bin/mkdir -p ${fDest%/*}
$ cygcheck -f /etc/postinstall/base-files-profile.sh
base-files-3.8-3
$ cygcheck -c base-files-3.8
Cygwin Package Information
Package VersionStatus
base-files 3.8-3 OK
--
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/
Cygwin 1.7: Possible file permission errors in 'base-files'
The two files 'base-files-mketc.sh' and 'base-files-profiles.sh' included in the 'base-files' package have their permissions set to 644 while all other scripts in /etc/postinstall/ have their permissions set to 755. Is this a side-effect of 'base-files-profiles.sh' not completing without errors, or is this set in the packaging? (Technically, the files with the permission problems are /etc/postinstall/base-files-mketc.sh.done and /etc/postinstall/base-files-profiles.sh.done.) -- 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 1.7: Possible error in /etc/postinstall/base-files-profile.sh
'dirname' is /usr/bin/dirname. Does setup-1.7.exe set
PATH before running 'base-files-profile.sh'? If not,
then this would account for the error.
It is possible to rewrite the command without using
'dirname':
/bin/mkdir -p ${fDest%/*}
$ cygcheck -f /etc/postinstall/base-files-profile.sh
base-files-3.8-3
$ cygcheck -c base-files-3.8
Cygwin Package Information
Package VersionStatus
base-files 3.8-3 OK
It does set the path. This is one of those cases where we really do
need to see the cygcheck output:
Included below (as an attachment) is the file generated by:
$ cygcheck -s -v -r cygcheck.out
Cygwin Configuration Diagnostics
Current System Time: Sat Jun 20 13:01:52 2009
Windows XP Media Center Edition Ver 5.1 Build 2600 Service Pack 3
Path: C:\cygwin-1.7\usr\local\bin
C:\cygwin-1.7\bin
C:\cygwin-1.7\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
Output from C:\cygwin-1.7\bin\id.exe (nontsec)
UID: 1007(a_user) GID: 513(None)
0(root) 544(Administrators) 545(Users) 513(None)
Output from C:\cygwin-1.7\bin\id.exe (ntsec)
UID: 1007(a_user) GID: 513(None)
0(root) 544(Administrators) 545(Users) 513(None)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
PWD = '/etc/postinstall'
CYGWIN = 'tty'
HOME = '/home/a_user'
HOMEPATH = '\Documents and Settings\a_user'
APPDATA = 'C:\Documents and Settings\a_user\Application Data'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel'
WINDIR = 'C:\WINDOWS'
WINDOWID = '8096040'
OLDPWD = '/etc'
USERDOMAIN = 'AHOSTNAME'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/c/DOCUME~1/a_user/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Common Files\GTK\2.0\bin'
QTJAVA = 'C:\Program Files\Java\jre1.5.0_02\lib\ext\QTJava.zip'
USERNAME = 'a_user'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
__COMPAT_LAYER = 'EnableNXShowUI '
USERPROFILE = 'C:\Documents and Settings\a_user'
LOGONSERVER = '\\AHOSTNAME'
PROCESSOR_ARCHITECTURE = 'x86'
SHLVL = '1'
COLORFGBG = '0;default;15'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/c/DOCUME~1/a_user/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PROCESSOR_REVISION = '0f06'
CLASSPATH = '.;C:\Program Files\Java\jre1.5.0_02\lib\ext\QTJava.zip'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = ':0'
NUMBER_OF_PROCESSORS = '2'
SESSIONNAME = 'Console'
COMPUTERNAME = 'AHOSTNAME'
COLORTERM = 'rxvt-xpm'
_ = '/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu2\Programs\Cygwin
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = '/'
cygdrive flags = 0x002a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = 'C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/desktop
(default) = 'c:\Documents and Settings\a_user\Desktop'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = 'C:\cygwin/bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = 'C:\cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
(default) = 'C:\cygwin-1.7'
obcaseinsensitive set to 1
c: hd NTFS 55623Mb 72% CP CS UN PA FC
d: hd FAT32 6991Mb 49% CPUN RECOVERY
e: cd N/AN/A
C:\cygwin-1.7 / system binary,auto
c:\Documents and Settings\a_user\Desktop /desktop system binary
C:\cygwin-1.7\bin /usr/bin system binary,auto
C:\cygwin-1.7\lib /usr/lib system binary,auto
cygdrive prefix / user
binary,posix=0,auto
Found: C:\cygwin-1.7\bin\awk.exe
Found: C:\cygwin-1.7\bin\awk.exe
- C:\cygwin-1.7\bin\gawk.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cp.exe
Found: C:\cygwin-1.7\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\WINDOWS\system32\find.exe
Cygwin 1.7: Uninstalling all (base) packages using setup-1.7.exe
After installing all default, base packages in Cygwin, I attempted to uninstall this base set by clicking on the cycle button/icon of the 'All' category (while the setup view for packages was set to 'Category') until 'Uninstall' was displayed for 'All' and for all sub-categories. When I clicked the 'Next' button, setup displays a window with the following text: Warning! Unmet Dependencies Found The following packages are required but have not been selected. Package: bash Required by: _update-info-dir Package: cygwin Required by: gcc4-runtime, libproj0, Numeric, _update-info-dir Package: python Required by: Numeric Package: texinfo Required by: _update-info-dir Should not 'setup' be uninstalling '_update-info-dir' and the other packages listed? When I removed the check from the check-box labeled: Install these packages to meet dependencies (RECOMMENDED) and click the 'Next' button, the following warning message is displayed: WARNING - Required Packages Not Selected If you continue without correcting the listed conflicts, your Cygwin installation will not function properly. We strongly recommend that you let Setup install the listed packages. Are you sure you want to proceed? After clicking on 'Yes', setup runs to completion and includes the text Installation Status: Uninstalls complete. -- 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/
Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh
After running setup-1.7.exe to install the package 'rxvt', I found the following error in /var/log/setup.log.full: 2009/06/20 16:00:17 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/rxvt.sh Using the default version of /etc/X11/app-defaults/Rxvt (/etc/defaults/etc/X11/app-defaults/Rxvt) /bin/touch: cannot touch `/etc/X11/app-defaults/Rxvt': No such file or directory /bin/cp: cannot create regular file `/etc/X11/app-defaults/Rxvt': No such file or directory The directory tree needed by the configuration file 'Rxvt' is missing. $ ls -l /etc/X11/app-defaults ls: cannot access /etc/X11/app-defaults: No such file or directory $ ls -l /etc/X11 ls: cannot access /etc/X11: No such file or directory Is the 'rxvt' package responsible for creating these missing directories? -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
Potential app conflicts: Logitech Process Monitor service Detected: HKLM Registry Key, Named process. You definitely need to stop and disable that service. It borks cygwin something rotten. Thank you. I will try that (anything to give my cygwin processes better behavior than they have now). Is this problem with the Logitech Process Monitor service described in the Cygwin documentation? -- 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: Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh
That having been said...rxvt is stealing a march by assuming /etc/X11/app-defaults/ exists. It's not clear -- if all the other packages did it the rxvt way -- WHO exactly should be responsible for creating the directory. 1. 'rxvt' is advertised as being available without X, so it cannot depend on X installation actions, can it? 2. What are packages' responsibilities are with respect to 'setup.exe'? Naive users should be able to install the base set of packages without any errors appearing in /var/log/setup.log*, correct? And they should be able immediately upon successfully installing the base set of packages, be able to un-install that set of packages without any errors appearing in /var/log/setup.log, I would expect. 3. If each of the packages was during installation to adopt the responsibility of: - Checking for every directory it needs - If the directory (tree) does not exist, create it - Populating the directories with the files it uses and then during un-installation, un-do what it did during installation: - Remove any (non-modified configuration) files - Remove any directory (trees) that it created during installation (using 'rmdir --ignore-fail-on-non-empty') then 'setup.exe' ought to be able to install/uninstall reproducibly without errors. I'll enhance the rxvt postinstall script to handle that in a future release. Thank you. -- 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: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh
Dave Korn wrote: Is this problem with the Logitech Process Monitor service described in the Cygwin documentation? http://cygwin.com/faq/faq.using.html#faq.using.bloda Thanks again for the additional information. I will be working my way through the entire FAQ at that link. http://cygwin.com/acronyms#BLODA From that link: FYI For Your Information. Also Fix Yourself It (for all the Star Wars fans out there) Perhaps, DIY (Do It Yourself) could be added. My guess is that it is more commonly used and understood than fix yourself it. I am not yet using cygwin 1.7. I am trying to install it (and un-install it) as I think a naive user might. I read the following two links that were provided with the announcement for cygwin-1.7.0-50: We have a new User's Guide for 1.7, which is currently located at http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html and And we have a new FAQ, though very likely not quite complete since we still don't know what exactly *is* a FAQ related to Cygwin 1.7. http://cygwin.com/1.7/faq/faq.html I see that at http://cygwin.com/1.7/faq/faq.setup.html, item 8 references the link that you provided under the heading My computer hangs when I run Cygwin Setup! My computer is not hanging -- it is just issuing error messages during install/un-install using setup-1.7.exe. -- 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] [1.7] Updated: cygwin-1.7.0-50
While running setup-1.7.exe (with no arguments) from a cygwin 1.5 bash shell prompt, the following (error?) messages were displayed: io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/mirrors-lst) failed 2 No such file or directory Are these messages expected? Can they be safely ignored? Are they documented somewhere for cygwin users? I was not able to find a mention of them at http://cygwin.com/1.7/faq/faq.setup.html or http://cygwin.com/1.7/cygwin-ug-net/setup-net.html Also, during the installation of the (default set of) packages, the following error message was displayed: running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/base-files-profile.sh abnormal exit: exit code=-1073741819 I confirmed that all directories and files that /etc/postinstall/base-files-profiles.sh creates or installs exist. I re-ran setup-1.7.exe a second time (with no additional packages selected) and found that none of the above messages were displayed. -- 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
Yes, but nevertheless the TERM setting needs to fit the terminal that Emacs is actually running in, so rxvt (or some variation thereof) for rxvt and xterm for xterm or mintty. As Ken said, the Eterm setting is intended for programs that run inside emacs' builtin terminal. Using Eterm* outside that might appear to work because many of its capabilities will be the same as with other terminals, but there will also be things that don't fit. Let's consider the case of the Cygwin Bash Shell (which runs the batch file 'cygwin.bat'). In this case, we do not want to set TERM (which defaults to 'cygwin') to 'Eterm-256color'. If we do, then terminal-mode emacs will attempt to use capabilities that Cygwin bash running inside cmd.exe does not support. So, the general principal of not exceeding the capabilities of the terminal that the application is running in is correct. Similarly, if we were running Emacs in a physical terminal, then we would need to be careful to tell Emacs about the correct set of control strings to send to the terminal. Of course, we are not generally, with Cygwin, running Emacs on a physical terminal so we do not have the restrictions of, say, a VT100. Leaving aside the very limited Cygwin Bash Shell and physical terminals, do the Cygwin terminal emulators have some capabilities that 'Eterm-256color' restricts, or, conversely, does 'Eterm-256color' attempt to use some capability that the terminal emulators do not support? If so, then I would like to know what they are. Here are some differences between the terminfo capabilities 'rxvt-cygwin-native' and 'Eterm-256color': 1. max_colors: rxvt- max_colors: 8 Eterm - max_colors: 256 We do not want to limit Emacs to 8 colors, and having Eterm-256color set the value to 256 does not cause any problem for rxvt. 2. auto_left_margin: rxvt- False Eterm - True So, when you reach the left margin in rxvt, it will not automatically wrap back to the previous line. In Eterm, you will. Does it matter for Emacs? No. 3. key_f0 / key_help: rxvt- key_f0: \E[21~, key_help: NULL Eterm - key_f0: NULL, key_help: \E28~ So, rxvt defines a Function key 0, which most modern keyboards do not have, correct? And Eterm defines the Help key, which modern keyboards do not have (this is not the F1 key). Neither key matters for Emacs. 4. key_a1, key_a3, key_c1, key_c3: These are the Home/PgUp/PgDn/End keys rxvt - \E0w, \E0y, \E0q, \E0s Eterm - \E[7~, \E[5~, \E[8~, \E[6~ Does this difference in key definitions matter in Cygwin's terminal-mode Emacs running in rxvt? No. A test reveals that Emacs translates the keycodes to the same control-char sequence regardless of whether Emacs is started with TERM set to 'rxvt-cygwin-native' or 'Eterm-256color': Home: ^[[7~ PgUp: ^[[5~ PgDn: ^[[6~ End: ^[[8~ I am attaching to this message a complete listing of the differences between the 'rxvt-cygwin-native' and the 'Eterm-256color' terminfo capability files. Please let me know if there is some critical capability that 'rxvt-cygwin-native' provides that 'Eterm-256color' lacks, or, conversely, if 'Eterm-256color' exceeds some capability of 'rxvt-cygwin-native' which results in defective behavior by Emacs. I would really like to know. Here are three reasons for using 'env TERM=Eterm-256color emacs...': 1. More distinct visual elements can be seen in Emacs's display. (I described what some of these were in a previous message.) The developers of Emacs have written it to make these elements available to provide information that would not be available otherwise. In general, we want to provide to Emacs the maximum number of terminal capabilities that we can so that the code can make use of those capabilities instead of using a lowest-common-denominator capability. 2. The appearance of terminal-mode Emacs more closely matches the default display of native-mode, windowing Emacs (either MS-Windows or X-Windows). 3. There is the possibility of a more consistent display across different terminal emulators (assuming that the terminal emulators will support the Eterm-256color capabilities). We now come back to the judgement question: In terminal- mode Emacs under Cygwin, would it be a better default for it to be started with TERM set to 'Eterm-256color'? If not, then -- specifically -- why not? What defects appear, that outweigh the benefits listed above? I would like to know what those are. And it would be helpful if replies were confined to those users who actually use terminal-mode Emacs, and who use it with the suggested TERM setting, preferably in 'rxvt', 'mintty', or 'screen' running in one of those terminal emulators. --- comparing rxvt-cygwin-native to Eterm-256color. comparing booleans. auto_left_margin: F:T. backspaces_with_bs: T:F. can_change: F:T. prtr_silent: F:T. comparing numbers. buttons: NULL, 5. lines_of_memory: NULL, 0. max_colors: 8, 256.
Re: Using emacs in a terminal window
I'd say it's a bug that the rxvt max_colors entry is 8, since rxvt does support 256 colours in its default setting. (And I notice it's the same with xterm.) Don't know whether there are compatibility concerns that require that. Just to be clear, the default terminfo capability for Cygwin rxvt is rxvt-cygwin-native, and that is what I used for comparison. There is no corresponding 'rxvt-cygwin-256color'. However, the correct way to address this is to set TERM to rxvt-256color (or xterm-256color, as appropriate) rather than Eterm-256color. That sounds reasonable and appears to be a really good suggestion (even if there is no 'rxvt-cygwin-256color'). I tried it and found that it appears to give a color/font/underlining capability identical to Eterm-256color, but it fixes a defect in Eterm-256color, namely, the mode line was not being shaded appropriately depending on which window in the frame was active. Using TERM=rxvt-256color, the mode-line highlighting now follows the active window, as expected. This appears to be the best default TERM setting for terminal-mode Emacs running in Cygwin (native) rxvt. env TERM=rxvt-256color emacs -nw ... Thank you for the suggestion! I will leave it to regular mintty+Emacs users to suggest the best default TERM setting for that terminal emulator. --- -- 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
First, note that this is not a Cygwin-specific issue. It is an Emacs-in-a-terminal issue, so perhaps it should not be mentioned at all in Cygwin-specific documents. It's similar to the backspace issue (or default fonts or default colors) in rxvt -- it leads to a better default user experience. But that is a judgement call for an experienced package maintainer, or a vote of the user community. I tried your suggestion and couldn't see that it improved anything. Whether you see any changes in font (bold versus non-bold), colors, underlining, and other screen capabilities will depend on what your terminal emulator's default TERM value is and on what type of file you are viewing. If terminal's default capabilities match the capabilities in the Emacs's terminal capability that you have selected for the types of files that you are editing, then you may not see any difference. One item that can be changed from what I wrote previously is the contingency of the 'terminfo' package. Because that package is included in the Base category, we should be able to assume that it is always installed. So, it should be possible to tell all users that they can start Emacs as follows: $ env TERM=Eterm-256color emacs -nw ... You will likely see differences if you compare that invocation of Emacs with this one: $ env TERM=rxvt-cygwin-native emacs -nw ... Some differences that I can see (in rxvt): 1. In Info mode, the Info menu (Next, Prev, Up, etc.) is highlighted for 'Eterm-256color', but not for 'rxvt-cygwin-native'. 2. The mode line is displayed highlighted similarly to the Info menu (regardless of whether in Info mode). 3. The font of keywords in assorted languages (shell-script, Emacs Lisp, C) is non-bold (easier for me to read) in 'Eterm-256color', but is 'bold' in 'rxvt-cygwin-native'. My reading of the documentation is that eterm-color is intended to be used by emacs when it does terminal emulation via 'M-x term'. No, when Emacs is run in terminal (text-only, non-X-windows) mode, it will use whatever terminal capability is in effect, not only in `term-mode'. See, for example, M-: (info (emacs) Remote Host) --- -- 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: Bug in $PATH initialization?
From the bash manual (in emacs: M-: (info (bash) Bash Startup Files)): When Bash is invoked as an interactive login shell, or as a non-interactive shell with the `--login' option, it first reads and executes commands from the file `/etc/profile', if that file exists. After reading that file, it looks for `~/.bash_profile', `~/.bash_login', and `~/.profile', in that order, and reads and executes commands from the first one that exists and is readable. The `--noprofile' option may be used when the shell is started to inhibit this behavior. and When an interactive shell that is not a login shell is started, Bash reads and executes commands from `~/.bashrc', if that file exists. This may be inhibited by using the `--norc' option. So, in the typical case, when you start bash with '-i', it sources the following files: /etc/profile # which typically contains PATH initialization ~/.bash_profile # or some other login file, such as ~/.profile ~/.bash_profile will usually source ~/.bashrc (the non-login code) To avoid having these files read, start bash with '--noprofile' (if you wish to avoid reading /etc/profile and ~/.bash_profile) and '--norc' (if you wish to avoid reading ~/.bashrc. Or, simply edit /etc/profile and ~/.bashrc, where PATH is typically set to get PATH to have the ordering that you want. -- 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
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. Here is an additional item related to terminal-mode Emacs that might be worth mentioning: A better display of colors, underlining, etc. can be obtained in the terminal mode Emacs by making use of the terminfo file that is included in the Emacs distribution: /usr/share/emacs/23.0.92/etc/e/eterm-color This file (eterm-color) can be accessed by copying it to the directory /usr/share/terminfo/e/ (which the user may need to create). The terminal capabilities are then available if terminal-mode Emacs is invoked with some variation of: env TERM=Eterm-color emacs ... If the user has the Cygwin version of the 'terminfo' package installed, then even more terminal capabilities are available. This package provides the files 'Eterm', 'Eterm-88color', and 'Eterm-256color' in the directory /usr/share/terminfo/45/. To make use of the 'Eterm-256color' terminal capabilities, for example, issue some variation of the following commands: $ cd /usr/share/terminfo/45/ $ ln -fs Eterm-256color Eterm-color $ cd $ env TERM=Eterm-color emacs ... An alias can also be defined to help: $ alias edit=env TERM=Eterm-color /usr/bin/emacs-nox --no-splash -- 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
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: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
Ken Brown wrote: New test release. cd release-2 wget -x -nH --cut-dirs=2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-23.0.92-1-src.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-23.0.92-1.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-X11/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-X11/emacs-X11-23.0.92-1.tar.bz2 \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-el/setup.hint \ http://www.math.cornell.edu/~kbrown/cygwin-1.7/emacs/emacs-el/emacs-el-23.0.92-1.tar.bz2 Please delete the 22.1-3 (test) packages, leaving 21.2-13 as current and 21.2-12 as previous. Ken In case you were unaware, Emacs version 23.0.93.1 (pre-release test) has been available for a few weeks. It might be worth considering providing both 23.0.92 and 23.0.93 so that you can work out how to maintain two versions: stable and unstable (not that .92 is more stable than .93).
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-1
Ken Brown wrote: On 5/14/2009 5:57 PM, Mark Harig wrote: In case you were unaware, Emacs version 23.0.93.1 (pre-release test) has been available for a few weeks. It might be worth considering providing both 23.0.92 and 23.0.93 so that you can work out how to maintain two versions: stable and unstable (not that .92 is more stable than .93). Yes, I knew about 23.0.93. I built it for myself and have been using it, just to make sure there were no regressions. If 23.0.92 proves stable enough to be promoted to current, then I'll think about doing something like what you suggested. But let's wait and see what happens when it gets released and people start using it. The transition from 21.2 to 23.0 might take some time for people to adapt to. Emacs 21.2 was released 7 years ago, and there's been quite a bit of development since then. Ken People who are willing to use the not-yet-released Cygwin 1.7 and the not-yet-released Emacs 23 ought to be expecting some instability. Alternatively, if Emacs 22.3 does not have compilation problems with Cygwin 1.7, then it could be provided as the Curr version, and one or more versions of Emacs 23 could be provided as Exp. In addition, providing more versions might help in your supporting Emacs -- if someone has a problem with one version of Emacs, then one troubleshooting strategy would be to have the user reproduce the problem on a later or earlier version. If the problem disappears, then you have narrowed down the source of the problem.
Re: Emacs maintainer
Ken Brown wrote: On 4/23/2009 1:36 PM, Ken Brown wrote: Steffen? Ping? There's been some discussion of the emacs-23 packages on the main cygwin list today (see the thread starting at http://cygwin.com/ml/cygwin/2009-05/msg00368.html). I really think these should be uploaded as test packages so more people can try them out. Ken Perhaps there should be two experimental versions of Emacs made available in the 'Exp' group in setup: - Emacs 22.3 (the latest release version of Emacs) - Emacs 23.0 (currently in pre-release testing) If version 22.3 is found to have resolved the problems that were found in version 22.1 (on Cygwin), then 22.3 could be moved to the 'Curr' group in setup as an alternative to version 21.2-13.
Re: ITP: tack-1.06-1
Charles Wilson wrote: cygwin-1.5: http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/ITP/tack-1.06-1.tar.bz2 Has the correct version of 'tack' been built and packaged? It appears that version 1.05 was built and packaged as version 1.06-1. $ cygcheck -c tack Cygwin Package Information Package VersionStatus tack 1.06-1 OK $ tack -V tack version 1.05 Copyright (C) 1997 Free Software Foundation, Inc. Tack comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of Tack under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. ---
Re: Updated: [Test-version] xemacs-21.5.28-3/xemacs-tags-21.5.28-3/xemacs-emacs-common-21.5.28-3
Dr. Volker Zell wrote: Hi A new *TEST* version of 'xemacs' has been uploaded to a server near you. The recently-announced update (February 01, 2009) to 'xemacs-emacs-common' appears to have re-introduced the problem described, below, namely, that the package 'xemacs-emacs-common' depends on the package 'xemacs'. The package 'xemacs-emacs-common' needs to be independent so that both emacs and xemacs users may install it without installing the other editor. Eric Blake writes: According to Angelo Graziosi on 7/19/2007 8:51 AM: 1) Emacs22 depend on xemacs-emacs-common which depend from xemacs: WHY to install emacs one should install XEmacs ? That sounds like a backwards dependency. Volker, shouldn't it be that xemacs depends on xemacs-emacs-common, and that xemacs-emacs-common is standalone? If you agree, I can change the setup.hints. You're right, my fault. I don't have sourceware access today. So please change the setup hint. (also from the xemacs test version please) Ciao Volker
Re: Updated: [Test-version] xemacs-21.5.28-3/xemacs-tags-21.5.28-3/xemacs-emacs-common-21.5.28-3
More explicitly,
xemacs -- depends on/requires -- xemacs-emacs-common
and
emacs -- depends on/requires -- xemacs-emacs-common
It might be clearer if 'xemacs-emacs-common' was renamed using the
plural for
emacs, that is, 'emacsen-common'. Also, I'm not sure that the package
should have the same version number ('21.5.28.3') as xemacs. That
versioning
suggests that it is a part of xemacs when it is shared by both emacs and
xemacs.
Dr. Volker Zell wrote:
Hi
A new *TEST* version of 'xemacs' has been uploaded to a server near you.
The recently-announced update (February 01, 2009) to
'xemacs-emacs-common'
appears to have re-introduced the problem described, below, namely, that
the package 'xemacs-emacs-common' depends on the package 'xemacs'. The
package 'xemacs-emacs-common' needs to be independent so that both emacs
and xemacs users may install it without installing the other editor.
Eric Blake writes:
According to Angelo Graziosi on 7/19/2007 8:51 AM:
1)
Emacs22 depend on xemacs-emacs-common which depend from xemacs:
WHY to
install emacs one should install XEmacs ?
That sounds like a backwards dependency. Volker, shouldn't it be
that
xemacs depends on xemacs-emacs-common, and that
xemacs-emacs-common is
standalone? If you agree, I can change the setup.hints.
You're right, my fault. I don't have sourceware access today. So please
change the setup hint. (also from the xemacs test version please)
Ciao
Volker
Re: Cygwin emacs
Corinna Vinschen wrote: Steffen, are you still with us? A mail on the Cygwin ML(*) indicated that the latest Cygwin emacs release 22.1 is still in test. The last message from you is from July 2007, so I'm a bit concerned that you just dropped off from Cygwin again. Do you further maintain Cygwin emacs? If so, can we take 22.1 out of test or are you going to prepare a new release? Thanks, Corinna Steffen can speak more definitively about this, but back in July there were run-time problems with the Cygwin version of Emacs 22.1. The apparent cause of the problem(s) was that Emacs was being built with gcc 3 instead of gcc 4, which is not available for Cygwin. My understanding of the hoped-for path to resolving this is: Resolve problems that are preventing a Cygwin gcc 4 - Compile Emacs 22.1 with gcc 4 - Test to determine whether the run-time problems have been resolved.
Re: [RFU] lzma-4.43-2
Christopher Faylor wrote: So, to reiterate: cygwin-apps is not a bug-reporting mailing list and, if you are a package maintainer, you should be monitoring the cygwin mailing list. Request for clarification: When is a problem a packaging issue and when is it a bug report? - Problems with packaging (omitted files, mis-configured /etc settings, continuing to include obsolete files, incorrect setup.ini hint, etc.) should be reported to 'cygwin-apps'. - Problems with running an application should be reported to 'cygwin'. Is this distinction correct? Is is complete?
Re: Prerequisites for generating clisp
Reini Urban wrote: More on-topic: The Cygwin clisp (2.43 and 2.44) fails to pass the test suite in the tests subdirectory: $ cd clisp-2.44-1/src/clisp-2.44/tests/ $ clisp -q Wrong! You have to override the character set from your console for those tests. See the Makefile. clisp -norc -E 1:1 as minimal cmdline. make check is preferred. Just some module specific tests are not yet included in the make check testsuite and have to be done manually. [1] (load tests) ;; Loading file /usr/src/clisp-2.44-1/src/clisp-2.44/tests/tests.lisp ... ;; Loaded file /usr/src/clisp-2.44-1/src/clisp-2.44/tests/tests.lisp T [2] (run-all-tests) ;;; many tests passed successfully, followed by: (PROGN (DEF-CALL-OUT C-SELF (:NAME ffi_identity) (:ARGUMENTS (FIRST (C-ARRAY-PTR UINT8))) (:RETURN-TYPE C-STRING) (:LANGUAGE :STDC)) (C-SELF #(230 151 165 230 156 172 232 170 158))) ERROR!! *** - Character #\u65E5 cannot be represented in the character set CHARSET:CP1252 The following restarts are available: ABORT :R1 ABORT Break 1 FTEST[3] Thank you for the correction. I had been following the instructions in the (out of date?) README file in the tests subdirectory. (Note: There is no 'check' target in the Makefile in the tests subdirectory. Instead, there is a 'tests' target.) I attempted the command that you suggested (i.e., clisp -norc -E 1:1) but it failed the test suite, too. I see now that the test suite cannot be used in a standalone fashion, but needs to be used within the cygport framework. Within that framework, the generated lisp passes all of the tests in the suite (i.e., none of the 10,812 tests failed).
Prerequisites for generating clisp
In the file /usr/share/doc/Cygwin/clisp-xx.README is the following information: Runtime recommendations: (-k full) fgci libdb4.5 libgdbm4 libpq4 Is the 'libpq4' run-time recommendation going to be changed to 'libpq5'? Build requirements: libsigsegv and the usual build tools I attempted to generate the Cygwin clisp package using: $ cygport /usr/src/clisp-2.xx.cygport prep compile This required multiple passes (using 'cygport ... finish' to remove each earlier pass) because additional header files are needed. Here is a list of the additional Cygwin packages that were needed: libdb4.5-devel (current version 4.5.20-2) libfcgi-devel and libfcgi0 (current version 2.4.0-2) pcre-devel (current version 7.2-1) libpq-devel (current version 8.1.4-2) This list is not complete because I do not have Cygwin/X installed, and so the 'cygport ... compile' process stopped (failed to compile due to missing X header files) when it attempted to generate the 'clx/new-clx' module. Could the above prerequisites be added to the Cygwin-specific README file (unless I have made some fundamental error) in the 'Build requirements' section? Of course, any other Cygwin packages that are required to generate 'clisp' by the 'cygport ... compile' process (for example, xorg-x11-devel) should be added to the 'Build requirements' section, also.
Using the '--with-ffcall' configuration option with 'clisp'
I wrote: There appears to be a contradiction between the Cygwin announcement and the upstream clisp announcement. The upstream announcement states that the configuration option '--with-dynamic-ffi' has been replaced by the option '--with-ffcall', but the Cygwin announcement states that the no-longer-supported '--with-dynamic-ffi' configuration option was used. Reini Urban wrote: I couldn't get it with --with-ffcall to find the ffcall libs on my build machine, --with-dynamic-ffi works still fine. On my development laptop --with-ffcall worked okay. The end product is the same. When I attempted to generate 'clisp' using 'cygport ... compile' using the 'clisp-2.44-1.cygport' provided by 'setup', errors were generated when gcc attempted to link 'lisp.exe' (error messages included at the end of this message). So, I replaced '--with-dynamic-ffi' with '--with-ffcall' in CYGCONF_ARGS in clisp-2.44-1.cygport. This initially did not fix the problem when I re-ran 'cygport ... compile' (presumably because of cached configuration results?). I restarted the process with 'cygport ... finish prep compile', and this eliminated the compilation errors (i.e., the 'gcc' linker command included the static libraries /usr/lib/libavcall.a and /usr/lib/libcallback.a). Could you update the clisp '.cygport' file to use '--with-ffcall' instead of '--with-dynamic-ffi', or is there some other factor I am not considering? P.S., The generated lisp appears to be quite good (from the clisp .log file): finished 52 files: 0 errors out of 10,812 tests - Link error messages: gcc -O2 -pipe -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DNO_GETTEXT -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o ari80386.o gllib/uniwidth/width.o gllib/uniname/uniname.o gllib/localcharset.o modules.o -lncurses -L/usr/lib -lsigsegv -o lisp.exe foreign.o:foreign.c:(.text+0xa80): undefined reference to `_is_trampoline_r' foreign.o:foreign.c:(.text+0xaa4): undefined reference to `_trampoline_r_address' foreign.o:foreign.c:(.text+0xaa9): undefined reference to `___vacall_r' foreign.o:foreign.c:(.text+0xab3): undefined reference to `_trampoline_r_data0' foreign.o:foreign.c:(.text+0xac2): undefined reference to `_trampoline_r_data1' foreign.o:foreign.c:(.text+0xb78): undefined reference to `_free_trampoline_r' foreign.o:foreign.c:(.text+0xbf6): undefined reference to `_is_trampoline_r' foreign.o:foreign.c:(.text+0xc02): undefined reference to `_trampoline_r_address' foreign.o:foreign.c:(.text+0xc07): undefined reference to `___vacall_r' foreign.o:foreign.c:(.text+0xc7f): undefined reference to `_trampoline_r_data0' foreign.o:foreign.c:(.text+0xc8e): undefined reference to `_trampoline_r_data1' foreign.o:foreign.c:(.text+0x43e4): undefined reference to `___structcpy' foreign.o:foreign.c:(.text+0x4f3a): undefined reference to `___va_error1' foreign.o:foreign.c:(.text+0x4fa4): undefined reference to `___va_error1' foreign.o:foreign.c:(.text+0x4fcb): undefined reference to `___va_error1' foreign.o:foreign.c:(.text+0x5007): undefined reference to `___va_error1' foreign.o:foreign.c:(.text+0x5079): undefined reference to `___va_error1' foreign.o:foreign.c:(.text+0x5094): more undefined references to `___va_error1' follow foreign.o:foreign.c:(.text+0x6cc8): undefined reference to `___vacall_r' foreign.o:foreign.c:(.text+0x6ccd): undefined reference to `_alloc_trampoline_r' foreign.o:foreign.c:(.text+0x7ddf): undefined reference to `___vacall_r' foreign.o:foreign.c:(.text+0x7de4): undefined reference to `_alloc_trampoline_r' foreign.o:foreign.c:(.text+0x88c9): undefined reference to `___builtin_avcall' foreign.o:foreign.c:(.text+0x4fee): undefined reference to `___structcpy' collect2: ld returned 1 exit status make: *** [lisp.exe] Error 1 *** ERROR: configure failed
Re: Prerequisites for generating clisp
Reini Urban wrote:
New is to build only a subset of the modules
cygmake MODULES=${MODULES}
And build the rest for the three seperate packages extra with the
clisp-linkkit.
Just so I understand, this will allow clisp to be built without the GUI
modules?
Off-topic: Not to be picky, but 'seperate' is spelled 'separate'.
$ grep seperate clisp-2.44-1.cygport clisp-2.44-1.cygwin.patch
clisp-2.44-1.cygport:# for the seperate clisp-x packages:
clisp-2.44-1.cygport: # use the linkkit for the seperate modules
clisp-2.44-1.cygwin.patch:+* removed the GDI module to a seperate
clisp-gdi package
clisp-2.44-1.cygwin.patch:+* prepare for another new seperate clisp-x
package with the new-clx and gtk2 modules
More on-topic: The Cygwin clisp (2.43 and 2.44) fails to pass the test
suite in the tests subdirectory:
$ cd clisp-2.44-1/src/clisp-2.44/tests/
$ clisp -q
[1] (load tests)
;; Loading file /usr/src/clisp-2.44-1/src/clisp-2.44/tests/tests.lisp ...
;; Loaded file /usr/src/clisp-2.44-1/src/clisp-2.44/tests/tests.lisp
T
[2] (run-all-tests)
;;; many tests passed successfully, followed by:
(PROGN (DEF-CALL-OUT C-SELF (:NAME ffi_identity) (:ARGUMENTS (FIRST
(C-ARRAY-PTR UINT8))) (:RETURN-TYPE C-STRING) (:LANGUAGE :STDC)) (C-SELF
#(230 151 165 230 156 172 232 170 158)))
ERROR!!
*** - Character #\u65E5 cannot be represented in the character set
CHARSET:CP1252
The following restarts are available:
ABORT :R1 ABORT
Break 1 FTEST[3]
Re: Prerequisites for generating clisp
Mark Harig wrote: Build requirements: libsigsegv and the usual build tools I attempted to generate the Cygwin clisp package using: $ cygport /usr/src/clisp-2.xx.cygport prep compile This required multiple passes (using 'cygport ... finish' to remove each earlier pass) because additional header files are needed. Here is a list of the additional Cygwin packages that were needed: libdb4.5-devel (current version 4.5.20-2) libfcgi-devel and libfcgi0 (current version 2.4.0-2) pcre-devel (current version 7.2-1) libpq-devel (current version 8.1.4-2) This list is not complete because I do not have Cygwin/X installed, and so the 'cygport ... compile' process stopped (failed to compile due to missing X header files) when it attempted to generate the 'clx/new-clx' module. Could the above prerequisites be added to the Cygwin-specific README file (unless I have made some fundamental error) in the 'Build requirements' section? Reini Urban wrote: ffcall is just a build time requirement, not run-time. Linked statically. So, 'ffcall' should also be listed in the 'Build requirements' section?
Re: Updated: clisp-2.44-1 for cygwin
Reini Urban wrote: I've released the new upstream clisp-2.44 plus subpackages -clx, -gtk2 and -gdi for cygwin. Release focus: 7 - Major bugfixes ./configure --fsstnd=redhat --with-dynamic-ffi \ --with-module=rawsock --with-module=dirkey \ --with-module=bindings/win32 --with-module=berkeley-db \ --with-module=pcre --with-module=postgresql \ --with-module=fastcgi --with-module=zlib \ --with-module=gdbm --with-module=libsvm \ --prefix=/usr --build build (no changes) http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/NEWS 2.44 (2008-02-02) = User visible changes * CLISP does not come with GNU libffcall anymore. This is now a separate package and should be installed separately. Pass --with-libffcall-prefix to the top-level configure if it is not installed in a standard place. Option --with-dynamic-ffi is now replaced with --with-ffcall. There appears to be a contradiction between the Cygwin announcement and the upstream clisp announcement. The upstream announcement states that the configuration option '--with-dynamic-ffi' has been replaced by the option '--with-ffcall', but the Cygwin announcement states that the no-longer-supported '--with-dynamic-ffi' configuration option was used. Does the Cygwin announcement merely contain a typo (i.e., the new option was, in fact, used, but not described correctly), or was the Cygwin clisp package configured incorrectly, using the old option? If it is the latter, then this might explain the fact that 'cygcheck' reports that it cannot find 'cygfcgi-0.dll' for /lib/clisp-[version]/full/lisp.exe (where [version] is either 2.43 or 2.44). -- 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: Updated: clisp-2.44-1 for cygwin
Reini Urban wrote: I've released the new upstream clisp-2.44 plus subpackages -clx, -gtk2 and -gdi for cygwin. Thank you for updating clisp to the latest version. I am seeing a reproducible error when I attempt to use it. Error code 53 is returned when the '-K full' option is supplied to clisp: $ /usr/bin/clisp -norc -q -K full || echo $? 53 $ cygcheck -c cygwin clisp ffcall Cygwin Package Information Package VersionStatus clisp2.44-1 OK cygwin 1.5.25-7 OK ffcall 1.10-1 OK I attempted to eliminate this problem by reverting to the previous version of clisp, 2.43-2, but the same error number was returned. No such error is returned for the base set of modules for either version 2.43-2 or 2.44-1: $ /usr/bin/clisp -q -norc -K base || echo $? [1]_ Please let me know if there is some more environmental information that I can provide to help resolve this problem. -- 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: Updated: clisp-2.44-1 for cygwin
Larry Hall wrote: Sounds like it could be a missing dependency problem. Does 'cygcheck clisp' report any missing DLLs? No, it doesn't report any missing DLLs. Both versions 2.43-2 and 2.44-1 have the following report from cygcheck: $ cygcheck clisp Found: C:\cygwin\bin\clisp.exe C:\cygwin\bin\clisp.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll -- 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: Updated: clisp-2.44-1 for cygwin
Eric Blake wrote: $ cygcheck /lib/clisp-2.44/full/lisp c:\cygwin\lib/clisp-2.44/full/lisp.exe ... Error: could not find cygpq5.dll Was cygpq5.dll the only missing file reported? I repeated your command and found that cygfcgi-0.dll is also needed/missing. (See below for the full listing of cygcheck.) So, what is cygpq5.dll, and has it ever been in the distribution? It might be a typo (in the procedures that compile/link clisp). Possibly, 'cygpq.dll' is needed. It is a library included in the Cygwin package named 'libpq4'. Is there a newer version 'libpq5' that has not been created for Cygwin yet? $ cygcheck -f /usr/bin/cygpq.dll libpq4-8.0.7-1 The Clisp documentation specifies that the full set of modules will include a postgresql and a fastCGI module. The DLLs that provide this support appear to be missing. Full listing for cygcheck of the full and base lisps. $ cygcheck /lib/clisp-2.44/full/lisp.exe C:\cygwin\lib/clisp-2.44/full/lisp.exe C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygdb-4.3.dll Error: could not find cygfcgi-0.dll C:\cygwin\bin\cyggdbm-4.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygncurses-8.dll C:\cygwin\bin\cygpcre-0.dll Error: could not find cygpq5.dll C:\cygwin\bin\cygreadline6.dll C:\WINDOWS\system32\USER32.dll C:\WINDOWS\system32\GDI32.dll C:\cygwin\bin\cygz.dll C:\WINDOWS\system32\OLE32.dll C:\WINDOWS\system32\msvcrt.dll C:\WINDOWS\system32\OLEAUT32.DLL Error: could not find cygfcgi-0.dll Error: could not find cygfcgi-0.dll Error: could not find cygfcgi-0.dll Error: could not find cygfcgi-0.dll Error: could not find cygfcgi-0.dll By contrast, /lib/clisp-2.44/base/lisp.exe is not missing any libraries: $ cygcheck /lib/clisp-2.44/base/lisp.exe C:\cygwin\lib/clisp-2.44/base/lisp.exe C:\cygwin\bin\cygcrypt-0.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygncurses-8.dll C:\cygwin\bin\cygreadline6.dll C:\WINDOWS\system32\USER32.dll C:\WINDOWS\system32\GDI32.dll C:\WINDOWS\system32\OLE32.dll C:\WINDOWS\system32\msvcrt.dll C:\WINDOWS\system32\OLEAUT32.DLL -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: xemacs-21.4.21-1/xemacs-tags-21.4.21-1/xemacs-emacs-common-21.4.21-1
Dr. Volker Zell wrote: Hi A new version of `xemacs' has been uploaded to a server near you. xemacs-emacs-common appears to have had xemacs added as a pre-requisite package. This dependency should be removed so that emacs users can continue to install the shared package without requiring xemacs (and the requisite X windows packages). I would also like to suggest that the xemacs-emacs prefix be renamed to the commonly-used plural for emacs, that is, emacsen. -- 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] New package: scsh-0.6.7-2
Reini Urban writes: scsh - the scheme shell - has been added to the cygwin distribution. Thank you for providing this package. 1. This package is classified in 'setup' as a 'Misc' package. Should this package be classified as a 'Shell' package instead? 2. The manual page 'scsh.1.gz' in /usr/share/man/man1 has only 27 bytes in it. The manual page, 'scsh.man', included in the source for 'scsh' has 1982 bytes. Is there a defect in the scsh cygwin package (i.e., did the manual page get package incorrectly), or is this a problem with my cygwin installation? -- 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] New package: scsh-0.6.7-2
Christopher Faylor wrote: 1. This package is classified in 'setup' as a 'Misc' package. Should this package be classified as a 'Shell' package instead? It is in the category Interpreters under Debian so I've put it there for Cygwin as well. Note that some packages are in multiple categories. clisp, for example, is in the Interpreters and Shells categories. And the editors Emacs and Xemacs are in the Interpreters and Editors categories. scsh likely belongs in both the Interpreters and Shells categories. Many people will look for the Scheme shell in the Shells category. -- 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: [ITA] splint 3.1.1 - Check C programs for security vulnerabilities
Jari Aalto wrote: wget\ http://cygwin.cante.net/splint/splint-3.1.1-2.tar.bz2 \ http://cygwin.cante.net/splint/splint-3.1.1-2-src.tar.bz2 \ http://cygwin.cante.net/splint/setup.hint In case you were not aware, splint 3.1.2 has been released (www.splint.org). Thank you for taking this package on. ---
Re: [ANNOUNCEMENT] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3
Angelo Graziosi wrote: (As I discussed some time on this list and others, I use GCC-4.0.4 to build Emacs: with 3.4.4 the result is highly unstable (at least for me), but this does not seem the case of 21-3) OK. It does not appear that gcc 4.x will be available for Cygwin soon, according to the discussion that started with this message in May 2007: http://cygwin.com/ml/cygwin/2007-05/msg00184.html If you discover a repeatable set of steps that you can follow that will cause Emacs to crash, would you please post those to this list? They could be used as a test to tell whether Emacs has been built correctly. In addition, your steps might be tested with Emacs on another platform (most commonly, a UNIX-like system) to determine whether the problem is specific to the Cygwin implementation of Emacs. My guess is that the problem that you are seeing cannot be resolved easily. Here are three approaches that might be taken, none of which is trivial: 1. Identify the C code in the Emacs 22 source that needs to be back-ported to gcc 3.4.4 so that the problem you are seeing does not occur. A patch could then be applied to Emacs 22 so that it could run error free on Cygwin. 2. Make gcc 4.0.4 available for Cygwin. Get it tested and past the experimental stage. 3. Wait until gcc 4.2.x (or a later gcc 4.4, etc.) has been ported to Cygwin. --- -- 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] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3
Angelo Graziosi wrote:
Provide a detailed list of the steps that you took
to create your emacs binaries.
They are very simple and standard (from the build script):
LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \
../configure --prefix=${prefix_dir} || return 1
make LD='$(CC)' || return 1
These are (essentially) the same steps that are used in
the .cygport for creating the Cygwin version of Emacs.
Would you please do the following?
$ make distclean
$ LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \
../configure --prefix=${prefix_dir} configure.log 21
$ bzip2 configure.log
and then include configure.log.bz2 as an attachment to an email
message to this mailing list. This might provide enough information
to find out what is missing from the environment that is used to
build Emacs via cygport.
---
--
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: Emacs takes 100% CPU
I switched to the emacs 22.1 available through cygwin, and it seems fine. I also started cygserver (adding the environment variable). Is the xemacs-emacs-common package required for emacs 22.1 ? It can be, depending on whether you need to use the 'b2m' or 'rcs-checkin' programs that are normally included in emacs distributions. Because xemacs also includes these two programs, there was a conflict if someone attempted to install both the emacs and xemacs packages. (In many other distributions, conflicts like this have been resolved by creating packages with names such as 'emacsen-common'.) In addition, if you write programs in Emacs Lisp and want to use Emacs's tag feature, then you will need to install the 'ctags' package also because Emacs's 'etags' program is not being included in the Cygwin Emacs package. These requirements were listed in the announcement and in the Cygwin README for Emacs. --- -- 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] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3
Angelo Graziosi: Ken Brown wrote: Emacs-22.1-3 aborts with a core dump when I try to compile a large latex document I observe a similar behaviour with a document of about 43 page. The same thing happens using 'M-x compile' with a my application that gives about 2000 line of link errors: emacs simply dies! The problem doesn't occur with my cited build of emacs 22.1. The following information might be helpful in investigating this problem: 1. Provide a detailed list of the steps (Emacs commands) that you are running to reproduce the problem. This should include a document file that is input into Emacs, preferably included as an attachment to your message, and compressed using bzip2 or gzip. 2. Provide a detailed list of the steps that you took to create your emacs binaries. This should include a copy of the output of 'configure' (again, included as a compressed text file attached to your message). Unfortunately, the Emacs documentation is opaque about what environment must be available during the configuration stage. I, for one, will look at this information if you provide it to help investigate what is causing the problem. Others might find it useful, too. Once a solution has been found it should be possible to include the proper steps in the cygport for Emacs so that it can be used going forward with later releases of Emacs. --- -- 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: Emacs is coming back - all pleased?
Steffen Sledz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake schrieb: Go ahead and send a release announcement, so hopefully you can get some more testers willing to try the version while it is still experimental. Is there a template for such announcements? Because 'etags' has been removed from the standard Emacs distribution, it would be good for the announcement and the cygwin.readme for Emacs to notify users that they will need to install the (exhuberant) ctags package if they want to generate tag files for Emacs Lisp. This is a standard, documented feature of Emacs so users should be made aware of why it will not work if they only install the base Cygwin installation plus Emacs. Alternatively, the 'etags' program could be removed from the ctags package (which still provides etags via the '-e' command-line option) and restored to the Emacs package. ---
Re: Emacs is coming back - all pleased?
Mark Harig wrote: Steffen Sledz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake schrieb: Go ahead and send a release announcement, so hopefully you can get some more testers willing to try the version while it is still experimental. Is there a template for such announcements? Because 'etags' has been removed from the standard Emacs distribution, it would be good for the announcement and the cygwin.readme for Emacs to notify users that they will need to install the (exhuberant) ctags package if they want to generate tag files for Emacs Lisp. This is a standard, documented feature of Emacs so users should be made aware of why it will not work if they only install the base Cygwin installation plus Emacs. Correction about the Cygwin README for Emacs: I see that /usr/share/doc/Cygwin/emacs-22.1.README already mentions the exuberant ctags dependency: Some binaries normally part of the emacs distribution are separated to avoid conflicts with other packages. If you need b2m or rcs-ckeckin install xemacs-emacs-common package. If you need ctags or etags install ctags package. Of course, the 'b2m' and 'rcs-checkin' binaries are already installed by default because the 'xemacs-emacs-common' package is a requirement of the Cygwin Emacs package. Alternatively, the 'etags' program could be removed from the ctags package (which still provides etags via the '-e' command-line option) and restored to the Emacs package. ---
Re: After Cygwin and XEmacs upgrade, read-only files aren't detected
On Sun, 2002-11-03 at 03:16, David M. Karr wrote: Mark == Mark Harig [EMAIL PROTECTED] writes: Mark With the most recent version of Cygwin, 1.3.14, CYGWIN has been set to Mark 'ntsec' by default. Unfortunately, this doesn't show up in the output Mark of 'cygcheck -s -r -v'. Ok, I guess that's the change that has created this symptom. Mark You might want to consider running the Microsoft 'convert' utility on Mark your disk to convert your filesystem from FAT32 to NTFS. The filesystem on my disk is already NTFS. Is there something in the cygcheck output that indicates it's fat32? Nothing in cygcheck (that I know of). If you're using NTFS, and changing CYGWIN=ntsec (the default) to CYGWIN=nontsec solves a problem with file permissions, then there is something else going on. Normally, if the filesystem on your disk(s) is NTFS then you want CYGWIN=ntsec in order to get the UNIX-like file permissions. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: After Cygwin and XEmacs upgrade, read-only files aren't detected
Please provide that output of 'cygcheck -s -r -v' *as an attachment*, as described in http://cygwin.com/bugs.html. If it is is not included as an attachment, then these mailing-list archives are made much less useful because many more false matches are listed during a search. On Sat, 2002-11-02 at 02:46, David M. Karr wrote: Last night I upgraded my Cygwin and Cygwin/XEmacs installations to the latest. Today, I noticed that XEmacs can no longer notice that read-only files are read-only. Normally, it detects that, and sets the buffer to be read-only. I did report this to the XEmacs group, but they're not aware of any recent changes that could be related to this. Is there some recent Cygwin feature change that could be causing this? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
