Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
On 01/01/2010 01:55, Duane Krings wrote: For of those of us who prefer the X window managers, I would like to request an option to this new command that starts the server _not_ in multiwindow mode as there is no -singlewindow or -nomultiwindow options we can send to the server as overrides. startx Yaakov Cygwin/X -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
IMPORTANT: THE startxwin.bat AND startxwin.sh SCRIPTS ARE NO LONGER SUPPORTED. I used to add the following option to XWin command because my screen resolution is now always recognized automatically: -screen 0 1920x1200 How can I do the same using .startxwinrc? Frédéric -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't start xterm from Cygwin/X icon in system tray
On 12/31/2009 1:43 PM, Yaakov (Cygwin/X) wrote: This sounds like it has nothing to do with startxwin. I can't reproduce this, but do any of the following help: 1) creating a ~/.startxwinrc containing just xterm ? Same problem. No xterm. 2) changing that .startxwinrc to run xterm? Pop-up: Couldn't find xterm anywhere. I even looked in the PATH Same when I tried run /usr/bin/xterm (couldn't find /usr/bin/xterm anywhere etc.) 3) setting LANG=en_US.ISO-8859-1 ? No change. 4) installing the font-daewoo-misc, font-isas-misc, and font-jis-misc packages? Those fonts are already installed. As I said, I have a desktop icon for starting an XTERM that works. It only doesn't work when trying to start the xterm from ~/.startxwinrc, or from the system tray. - Jim -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
On 01/01/2010 04:30, Frédéric Bron wrote: I used to add the following option to XWin command because my screen resolution is now always recognized automatically: -screen 0 1920x1200 How can I do the same using .startxwinrc? From the announcment: startxwin also accepts command line arguments to use a different DISPLAY number and add additional options to pass to the server. Please read the startxwin(1) manpage, which describes both the command-line arguments accepted by startxwin and the format of the $HOME/.startxwinrc file. Yaakov Cygwin/X -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
I used to add the following option to XWin command because my screen resolution is now always recognized automatically: -screen 0 1920x1200 How can I do the same using .startxwinrc? From the announcment: startxwin also accepts command line arguments to use a different DISPLAY number and add additional options to pass to the server. Please read the startxwin(1) manpage, which describes both the command-line arguments accepted by startxwin and the format of the $HOME/.startxwinrc file. I have read that but it was not clear to me. I suspect that I should write -- before the -screen option? Is that true? Frédéric -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Alt key not recognized as Meta in xterm
2009/12/30 Gary Carvell: X issues including xterm ones should go to the cygwin-xfree list. I'm sending this to both lists, but please respond on cygwin-xfree only. With the upgrade to Cygwin 1.7, I found that the Alt key is no longer recognized as a Meta key in xterm. This means the Alt based command line editing keys such as Alt-F/B for forward- and backward-word must be entered with the Esc key instead. I assume this is related to the internationalization changes in 1.7. I liked the old behavior better, but had some trouble changing it back. So here's my little hack for this in case anyone else finds it useful. In your home directory, create a file .Xdefaults containing this line: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. When that option is not enabled, 'meta' is sent by setting the highest bit of the metafied character, e.g. 'f' (0x66) turns into 0xE6. That's fine if you're using ASCII only, but obviously it'll conflict with any character encodings beyond ASCII, e.g.in ISO-8859-1 and others, 0xE6 is æ (the ae ligature). And in UTF-8, which of course is the Cygwin default now, a 0xE6 byte would be an incomplete sequence. That's why xterm applies the meta bit before doing the UTF-8 encoding, so Alt-f is sent as \xC3\xA6, which is the UTF-8 encoding for U+00E6 (again: æ) . But bash doesn't recognise that as Alt-f. I'd be glad to hear any background information on the key mapping change, or better ways to restore the old behavior. If you don't need anything beyond ASCII, you could go back to a singlebyte charset, e.g. by setting 'LANG=en_US.ISO-8859-1'. Otherwise, the escape prefix is the way to go. Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Alt key not recognized as Meta in xterm
On Fri, 1 Jan 2010, Andy Koppe wrote: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. However, the reason that it's not is because there's no standard for the meta key assignment. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Alt key not recognized as Meta in xterm
2010/1/1 Thomas Dickey: On Fri, 1 Jan 2010, Andy Koppe wrote: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. However, the reason that it's not is because there's no standard for the meta key assignment. Understood. I didn't mean it should be the default for Xterm in general, but it should be for Cygwin's version, due to UTF-8 being the default charset. Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Alt key not recognized as Meta in xterm
On Fri, 1 Jan 2010, Andy Koppe wrote: 2010/1/1 Thomas Dickey: On Fri, 1 Jan 2010, Andy Koppe wrote: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. However, the reason that it's not is because there's no standard for the meta key assignment. Understood. I didn't mean it should be the default for Xterm in general, but it should be for Cygwin's version, due to UTF-8 being the default charset. Is Cygwin also specifying a meta key? (some people equate meta==alt, though they're not necessarily the same) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Alt key not recognized as Meta in xterm
2010/1/1 Thomas Dickey: Is Cygwin also specifying a meta key? (some people equate meta==alt, though they're not necessarily the same) I don't know whether there's ever been an official policy decision on that, but I think the general assumption among Cygwin users is that Alt==Meta, since of course PC keyboards don't have a Meta key yet lots of programs expect one. I realise that in X it is possible to map a different key to Meta, but the altIsNotMeta setting is off by default in Cygwin's xterm. Also, the Cygwin console, rxvt, and mintty (via PuTTY) assume that Alt is Meta (and they all encode it as Escape by default). Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't start xterm from Cygwin/X icon in system tray
Are you executing startxwin from a login shell? I use \path\to\cygwin\bin\run.exe /bin/bash.exe -l -c /bin/startxwin.exe and it works for me. On Fri, 1 Jan 2010, Jim Reisert AD1C wrote: On 12/31/2009 1:43 PM, Yaakov (Cygwin/X) wrote: This sounds like it has nothing to do with startxwin. I can't reproduce this, but do any of the following help: 1) creating a ~/.startxwinrc containing just xterm ? Same problem. No xterm. 2) changing that .startxwinrc to run xterm? Pop-up: Couldn't find xterm anywhere. I even looked in the PATH Same when I tried run /usr/bin/xterm (couldn't find /usr/bin/xterm anywhere etc.) 3) setting LANG=en_US.ISO-8859-1 ? No change. 4) installing the font-daewoo-misc, font-isas-misc, and font-jis-misc packages? Those fonts are already installed. As I said, I have a desktop icon for starting an XTERM that works. It only doesn't work when trying to start the xterm from ~/.startxwinrc, or from the system tray. - Jim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Alt key not recognized as Meta in xterm
On Fri, 1 Jan 2010, Andy Koppe wrote: 2010/1/1 Thomas Dickey: Is Cygwin also specifying a meta key? (some people equate meta==alt, though they're not necessarily the same) I don't know whether there's ever been an official policy decision on that, but I think the general assumption among Cygwin users is that Alt==Meta, since of course PC keyboards don't have a Meta key yet lots of programs expect one. I realise that in X it is possible to map a different key to Meta, but the altIsNotMeta setting is off by default in Cygwin's xterm. Also, the Cygwin console, rxvt, and mintty (via PuTTY) assume that Alt is Meta (and they all encode it as Escape by default). iirc, Cygwin console (unless something's changed in 1.7) and rxvt don't actually do the meta function as described in the terminfo manpage, e.g., If the terminal has a ``meta key'' which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this ``meta mode'' on and off, they can be given as smm and rmm. Rather, they're assuming that meta is a way to put an escape character in front of other keys. That's reflected in readline's manpage: An emacs-style notation is used to denote keystrokes. Control keys are denoted by C-key, e.g., C-n means Control-N. Similarly, meta keys are denoted by M-key, so M-x means Meta-X. (On keyboards without a meta key, M-x means ESC x, i.e., press the Escape key then the x key. This makes ESC the meta prefix. The combination M-C-x means ESC-Control-x, or press the Escape key then hold the Control key while pressing the x key.) however (same manpage) convert-meta (On) If set to On, readline will convert characters with the eighth bit set to an ASCII key sequence by stripping the eighth bit and prefixing it with an escape character (in effect, using escape as the meta prefix). ... input-meta (Off) If set to On, readline will enable eight-bit input (that is, it will not clear the eighth bit in the characters it reads), regardless of what the terminal claims it can support. The name meta-flag is a synonym for this variable. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't start xterm from Cygwin/X icon in system tray
On 1/1/2010 12:41 PM, john wrote: Are you executing startxwin from a login shell? I use \path\to\cygwin\bin\run.exe /bin/bash.exe -l -c /bin/startxwin.exe and it works for me. Yes, my startup folder shortcut is: D:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe As I've said before, this works properly on my XP SP3 system at work, but not on my Windows 7 64-bit system at home. - Jim On Fri, 1 Jan 2010, Jim Reisert AD1C wrote: On 12/31/2009 1:43 PM, Yaakov (Cygwin/X) wrote: This sounds like it has nothing to do with startxwin. I can't reproduce this, but do any of the following help: 1) creating a ~/.startxwinrc containing just xterm? Same problem. No xterm. 2) changing that .startxwinrc to run xterm? Pop-up: Couldn't find xterm anywhere. I even looked in the PATH Same when I tried run /usr/bin/xterm (couldn't find /usr/bin/xterm anywhere etc.) 3) setting LANG=en_US.ISO-8859-1 ? No change. 4) installing the font-daewoo-misc, font-isas-misc, and font-jis-misc packages? Those fonts are already installed. As I said, I have a desktop icon for starting an XTERM that works. It only doesn't work when trying to start the xterm from ~/.startxwinrc, or from the system tray. - Jim -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog dcrt0.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-01-01 19:15:11 Modified files: cygwin : ChangeLog dcrt0.cc Log message: * dcrt0.cc (dll_crt0_1): Move internal locale setting prior to potential globify to prevent creation of unglobbed filenames in the wrong character set. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4756r2=1.4757 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dcrt0.cc.diff?cvsroot=uberbaumr1=1.367r2=1.368
winsup/cygwin ChangeLog dcrt0.cc ChangeLog-2009
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-01-01 19:28:15 Modified files: cygwin : ChangeLog dcrt0.cc Added files: cygwin : ChangeLog-2009 Log message: * dcrt0.cc: Bump copyright. Do the changelog shuffle. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog-2009.diff?cvsroot=uberbaumr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4757r2=1.4758 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dcrt0.cc.diff?cvsroot=uberbaumr1=1.368r2=1.369
Re: BSOD after major release
failures.) Yeh. A falling hippo will do that to your park zone. Youse guys wanna be careful there, somebody might burn it down! It had to happen. MITMDTPTP. -- 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: Symbolic links problem with cygwin 1.7.1 in 64-bit Win7 Command Prompt
This is a known limitation of the symbolic links in Cygwin 1.7. The solution is ... Thanks for the info. I'll try one of your workarounds. Cheers, Tuli -- 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
Appropriate expectation on the degree of cygwin and MS interoperability
Folks, A bit of a vague question but any greater clarity concerning the appropriate level of interoperability between Cygwin and MS would be appreciated. I have my Windows 6 and 7 platforms configured to build software using different toolchains, the most common being (1) Visual Studio 10 and (2) Cygwin with gcc-4. When using the Visual Studio toolchain I will prefer a cygwin tool over a MS tool, so for example, I always use bash and gnu make and never use the cmd shell/power shell or nmake. Taking this further, I will try to use nm over dumpbin and ar over lib. For the most part the cygwin tools interoperate with MS artifacts but it does break down, especially, with 64bit artifacts. For example, nm can work with 32bit object files created by MS cl.exe but it cannot work with 64bit MS object files (unrecognised file format). The question is: how far should I expect the interoperability to go? For example, is the fact that nm cannot handle 64bit MS object files a (1) defeat in cygwin/nm or (2) I should be grateful that it works with 32bit files and otherwise lower my expectation? I suppose at its core the question is about the intent of cygwin. Is it (1) to provide unix like capabilities to a MS platform (in which case one would expect/demand a high degree of interoperability), or (2) to provide a unix like island inside a MS platform? The problem with (2) is one cannot really stay isolated from the host MS environment. My previous question of how/if one can use cyginw *.h *.dll *.a artifacts in a MS compiled program is essentaily the same theme although I have lower expectations that it is possible. Any pointers? Regards, Neil -- 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: Appropriate expectation on the degree of cygwin and MS interoperability
On 1/1/2010 20:06, neil.mowb...@calgacus.com wrote: Folks, A bit of a vague question but any greater clarity concerning the appropriate level of interoperability between Cygwin and MS would be appreciated. I have my Windows 6 and 7 platforms configured to build software using different toolchains, the most common being (1) Visual Studio 10 and (2) Cygwin with gcc-4. When using the Visual Studio toolchain I will prefer a cygwin tool over a MS tool, so for example, I always use bash and gnu make and never use the cmd shell/power shell or nmake. Taking this further, I will try to use nm over dumpbin and ar over lib. For the most part the cygwin tools interoperate with MS artifacts but it does break down, especially, with 64bit artifacts. For example, nm can work with 32bit object files created by MS cl.exe but it cannot work with 64bit MS object files (unrecognised file format). The question is: how far should I expect the interoperability to go? For example, is the fact that nm cannot handle 64bit MS object files a (1) defeat in cygwin/nm or (2) I should be grateful that it works with 32bit files and otherwise lower my expectation? I suppose at its core the question is about the intent of cygwin. Is it (1) to provide unix like capabilities to a MS platform (in which case one would expect/demand a high degree of interoperability), or (2) to provide a unix like island inside a MS platform? The problem with (2) is one cannot really stay isolated from the host MS environment. My previous question of how/if one can use cyginw *.h *.dll *.a artifacts in a MS compiled program is essentaily the same theme although I have lower expectations that it is possible. Any pointers? Hi, for nm to recognize 64bit objects, you need to rebuild binutils to recognize 64bit objects. Use --enable-target=i686-pc-cygwin,x86_64-w64-mingw32 with binutils configure. Beware that MSVC now uses the short library format instead of the older long library format used by the GNU toolchain. See http://mingw-w64.sourceforge.net/ for toolchains targeting win64. IMHO Cygwin is more of an island, you're supposed to use Cygwin tools only under Cygwin. Others might have different opinions. -- 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: /var/lib/alternatives/gcc missing for alternatives 1.3.30c
Thanks folks. I did have a /etc/postinstll/gcc.sh.done but it was installing v3.0 so I modified to v4.0 and run it which solved the problem. Also apologies for not understanding how alternatives works -- all fixed now. Regards, Neil Larry Hall (Cygwin) wrote: On 12/30/2009 08:07 AM, neil.mowb...@calgacus wrote: Can someone please provide a valid /var/lib/alternatives/gcc file or link me to either it's syntax or the programs source? This is created when alternatives runs for gcc. If you're missing it, it suggests to me that alternatives wasn't run. Check '/etc/postinstall/gcc.sh* and /etc/postinstall/gcc-g++.sh*. If there is no done suffix, these didn't run, which is why you don't have the alternatives files you're looking for. If there is a done suffix, these did run but apparently didn't do so successfully. Try running them again by hand and see what errors, if any, pop up. Also, apologies: there was a packaging hiccup in the latest version, and the execute permissions got lost. If you try to just run set-gcc-default-[34].sh at the shell, you'll get a Permission denied error; you can either chmod a+x them, or use the . name (aka bash source builtin) syntax to invoke them. cheers, DaveK -Original Message- From: neil.mowb...@calgacus.com [mailto:neil.mowb...@calgacus.com] Sent: 30 December 2009 21:07 To: cygwin@cygwin.com Subject: /var/lib/alternatives/gcc missing for alternatives 1.3.30c Dear Folks, The scripts /bin/set-gcc-default-[34].sh are written to use alternatives to install gcc-3 and gcc-4. But /var/lib/alternatives/gcc is missing. I tried to create it using g++ as an example but all functions failed with an error failed to read link /usr/bin/gcc.exe (which is the orginal problem). I look for the source but the cygwin alternatives src tar ball doesn't contain the source nor can I find it on cygwin.com or with a quick google search. So I write this message. Can someone please provide a valid /var/lib/alternatives/gcc file or link me to either it's syntax or the programs source? Regards, Neil -- 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: Appropriate expectation on the degree of cygwin and MS interoperability
On 1/1/2010 20:37, JonY wrote: On 1/1/2010 20:06, neil.mowb...@calgacus.com wrote: Folks, A bit of a vague question but any greater clarity concerning the appropriate level of interoperability between Cygwin and MS would be appreciated. I have my Windows 6 and 7 platforms configured to build software using different toolchains, the most common being (1) Visual Studio 10 and (2) Cygwin with gcc-4. When using the Visual Studio toolchain I will prefer a cygwin tool over a MS tool, so for example, I always use bash and gnu make and never use the cmd shell/power shell or nmake. Taking this further, I will try to use nm over dumpbin and ar over lib. For the most part the cygwin tools interoperate with MS artifacts but it does break down, especially, with 64bit artifacts. For example, nm can work with 32bit object files created by MS cl.exe but it cannot work with 64bit MS object files (unrecognised file format). The question is: how far should I expect the interoperability to go? For example, is the fact that nm cannot handle 64bit MS object files a (1) defeat in cygwin/nm or (2) I should be grateful that it works with 32bit files and otherwise lower my expectation? I suppose at its core the question is about the intent of cygwin. Is it (1) to provide unix like capabilities to a MS platform (in which case one would expect/demand a high degree of interoperability), or (2) to provide a unix like island inside a MS platform? The problem with (2) is one cannot really stay isolated from the host MS environment. My previous question of how/if one can use cyginw *.h *.dll *.a artifacts in a MS compiled program is essentaily the same theme although I have lower expectations that it is possible. Any pointers? Hi, for nm to recognize 64bit objects, you need to rebuild binutils to recognize 64bit objects. Use --enable-target=i686-pc-cygwin,x86_64-w64-mingw32 with binutils configure. Beware that MSVC now uses the short library format instead of the older long library format used by the GNU toolchain. Correction: I mean .obj object file format, not the .lib library format. The latter stays mostly the same. -- 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
GCC, -rdynamic option is unrecognized by GCC.
Hello, - I am trying (without success) to compile this application (PCB): http://geda.seul.org/dist/pcb-20091103.tar.gz - configure work well. But... - When doing a make, there is a message telling: gcc: unrecognized option '-rdynamic' Followed by a ton of linker messages telling: ...: undefined reference to - I searched the cygwin mailing list archive about -rdynamic, and only found old 2001 mails that do not give workaround to be able to built such application without modifying the source code. - So, I have some questions: - How come Cygwin GCC do not still support -rdynamic option? - Is application using GCC -rdynamic option are not compatible with Cygwin? Claude. -- 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: BSOD after major release
From: Lee D. Rothstein l1ee...@veritech.com To: cyg...@cygwin.com Date: Fri, 01 Jan 2010 04:00:02 -0500 Subject: Re: BSOD after major release failures.) Yeh. A falling hippo will do that to your park zone. Youse guys wanna be careful there, somebody might burn it down! It had to happen. MITMDTPTP. Sorry for not responding - NY anyway :). So, I have Win XP + latest drivers updatets includding BIOS (that update dates only three days :)). I've tried do such thing with default inastallation from kernel.org mirror under safe mode + quick device profile. Both that two critical packages are skipped under default. I use to use device profiles in XP. Great thing - i can manually and quickly turn off almost all i don't like includding hidden drivers and services (My Computer/Properties/Devices/device profiles) So, in this configuration do not work too. Besides, bad_pool_header is rather memory leak error - and you had such issue before http://www.cygwin.com/ml/cygwin/2004-11/msg00862.html do not connect to that two packages. King regards, Sergey Ivanov -- 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: Appropriate expectation on the degree of cygwin and MS interoperability
neil.mowb...@calgacus.com wrote: For the most part the cygwin tools interoperate with MS artifacts but it does break down, especially, with 64bit artifacts. For example, nm can work with 32bit object files created by MS cl.exe but it cannot work with 64bit MS object files (unrecognised file format). The question is: how far should I expect the interoperability to go? For example, is the fact that nm cannot handle 64bit MS object files a (1) defeat in cygwin/nm or (2) I should be grateful that it works with 32bit files and otherwise lower my expectation? cygwin binutils doesn't set or understand /machine tags, which are required for 64-bit targets. The mingw32-64 project is a partial solution. I, too, would be grateful for a satisfactory solution which persuades cygwin make to use a 64-bit alternative to ar when needed. -- 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: gcc4[1.7] printf treats differently a string constant and a character array
Some comments: 1- I think that printf(string_constant) and printf(char_array) should give the same output in any circumstance. 2- In absence of a call to setlocale printf((string_constant) writes according to the locale of the environment, but printf(char_array) does not, even though it is affected by the locale of the environment. No, both work according to the C locale, with its UTF-8 character set, and behaviour for invalid UTF-8 sequences is undefined for both. Undefined means anything might happen, including inconsistent behaviour. (Requiring consistent behaviour would make the puts optimisation impossible.) 3- I think that a program that was written for locale=C should work without modification if the locale in the environment is any of the one-byte characters ones. 4- I think that a plain C (8-bit transparent) locale should be available, even if it is not the default one. If you don't call setlocale, all you can expect according to the C and POSIX standards is the so-called portable character set. So you shouldn't assume that the C locale is 8-bit transparent. However, since that is a valid assumption on Linux and others, Cygwin might indeed be better off following their example. There's a discussion about that on cygwin-developers. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Alt key not recognized as Meta in xterm
2009/12/30 Gary Carvell: X issues including xterm ones should go to the cygwin-xfree list. I'm sending this to both lists, but please respond on cygwin-xfree only. With the upgrade to Cygwin 1.7, I found that the Alt key is no longer recognized as a Meta key in xterm. This means the Alt based command line editing keys such as Alt-F/B for forward- and backward-word must be entered with the Esc key instead. I assume this is related to the internationalization changes in 1.7. I liked the old behavior better, but had some trouble changing it back. So here's my little hack for this in case anyone else finds it useful. In your home directory, create a file .Xdefaults containing this line: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. When that option is not enabled, 'meta' is sent by setting the highest bit of the metafied character, e.g. 'f' (0x66) turns into 0xE6. That's fine if you're using ASCII only, but obviously it'll conflict with any character encodings beyond ASCII, e.g.in ISO-8859-1 and others, 0xE6 is æ (the ae ligature). And in UTF-8, which of course is the Cygwin default now, a 0xE6 byte would be an incomplete sequence. That's why xterm applies the meta bit before doing the UTF-8 encoding, so Alt-f is sent as \xC3\xA6, which is the UTF-8 encoding for U+00E6 (again: æ) . But bash doesn't recognise that as Alt-f. I'd be glad to hear any background information on the key mapping change, or better ways to restore the old behavior. If you don't need anything beyond ASCII, you could go back to a singlebyte charset, e.g. by setting 'LANG=en_US.ISO-8859-1'. Otherwise, the escape prefix is the way to go. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Alt key not recognized as Meta in xterm
On Fri, 1 Jan 2010, Andy Koppe wrote: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. However, the reason that it's not is because there's no standard for the meta key assignment. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- 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: Alt key not recognized as Meta in xterm
2010/1/1 Thomas Dickey: On Fri, 1 Jan 2010, Andy Koppe wrote: XTerm*vt100.metaSendsEscape: true Actually that's not a hack, but the correct solution. I think this needs to be part of the default config in /etc/X11/app-defaults/XTerm. However, the reason that it's not is because there's no standard for the meta key assignment. Understood. I didn't mean it should be the default for Xterm in general, but it should be for Cygwin's version, due to UTF-8 being the default charset. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC, -rdynamic option is unrecognized by GCC.
On 2010-01-01 15:26Z, Claude Sylvain wrote: - How come Cygwin GCC do not still support -rdynamic option? http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html | Pass the flag -export-dynamic to the ELF linker, | on targets that support it. Cygwin uses PE, not ELF. -- 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 passes argv with preserved () quote. and it is undesired result.
On Thu, Dec 31, 2009 at 11:25:53AM -0500, Christopher Faylor wrote:
On Thu, Dec 31, 2009 at 05:00:25PM +0900, jojelino wrote:
hi
here is testcase to reproduce the problem
#include stdio.h
#include assert.h
int main(int argc, char**argv)
{
printf(argv %s,argv[1]);
open(argv[1],r);
assert(fp);
return 0;
}
build
make ��.txt in directory.
and run in cmd.exe
type,
a ��.txt
and it complains file can't be opened.
and you can see argv[1] is passed with preserved quote () although it is
invoked in winshell
it must be eliminted when it is transduced to cygwin environment.
I don't see preserved quotes but I do see that ARGV has apparently been
changed to UTF-8 and is represented as: -�-�.txt
Try setting LANG to something appropriate in your MS-DOS session and see
if that makes things work better.
I think I've fixed this problem in the upcoming cygwin snapshot at:
http://cygwin.com/snapshots/
if you want to give it a try. It will be in *today's* snapshot, not the
one from 12/29.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Missing #defines from cygwin windows.h
Folks, At least the following are missing from cygwin's windows.h #define FILE_ATTRIBUTE_VIRTUAL 0x0001 (from MS WinNT.h) #define SYMBOLIC_LINK_FLAG_DIRECTORY(0x1) (from MS WinBase.h) Regards, Neil -- 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: Missing #defines from cygwin windows.h
neil.mowb...@calgacus wrote: Folks, At least the following are missing from cygwin's windows.h (from MS WinNT.h) (from MS WinBase.h) Sorry, you (and we) can't do that. Copying and pasting definitions from Microsoft's proprietary header files is a no-no; we have to use publicly-available sources of information such as MSDN docs, IIUC. (In which case, http://msdn.microsoft.com/en-us/library/ee332330(VS.85).aspx and http://msdn.microsoft.com/en-us/library/aa363866(VS.85).aspx look like acceptable sources for the symbols referred to in the earlier post. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Symbolic links problem with cygwin 1.7.1 in 64-bit Win7 Command Prompt
2009/12/30 Larry Hall (Cygwin): I've been using gcc and other tools in older versions of cygwin with 32-bit Windows XP and Vista from windows command prompt (cmd.exe) without problems. But now I'm using 64-bit Windows 7, and some command line tools like gcc.exe do not work anymore (from cmd.exe). They do work ok from Cygwin's bash. [...] Another [solution] might be to set winsymlinks in the CYGWIN environment variable http://cygwin.com/cygwin-ug-net/using-cygwinenv.html and recreate the symlinks you want that way. That won't work. The option causes symlinks to be represented by Windows shortcuts, which do work in Explorer, but not in cmd.exe where they appear as .lnk files instead. (Lame, eh?) Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Missing #defines from cygwin windows.h
At least the following are missing from cygwin's windows.h (from MS WinNT.h) (from MS WinBase.h) Sorry, you (and we) can't do that. Copying and pasting definitions from Microsoft's proprietary header files is a no-no; we have to use publicly-available sources of information such as MSDN docs, IIUC. (In which case, http://msdn.microsoft.com/en-us/library/ee332330(VS.85).aspx and http://msdn.microsoft.com/en-us/library/aa363866(VS.85).aspx look like acceptable sources for the symbols referred to in the earlier post. Just to add on to what Dave mentioned, please submit a patch (using the publicly available information via the msdn links Dave provided) to the MinGW patch tracker (http://sourceforge.net/tracker/?group_id=2435atid=302435). The w32api package is maintained by the MinGW project. Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
old install instructions? -mnomingw being removed?
Sorry, I am a complete noob to all this make/install/gcc stuff, I am just trying to make a fresh build of a DLL I have used for years to see if it resolves a problem. I installed cygwin 1.7.1 today on a windows 7 laptop. The directions for my library are great: VER=8.4.12 SRCDIR=`pwd` cd $SRCDIR/tcl$VER/win env 'CC=gcc -mno-cygwin' ./configure --enable-threads make libtclstub84.a cd $SRCDIR/tk$VER/win env 'CC=gcc -mno-cygwin' ./configure --enable-threads make libtkstub84.a cd $SRCDIR/Togl env 'CC=gcc -mno-cygwin' ./configure --with-tcl=../tcl$VER/win --with- tk=../tk$VER/win make That's from doc for the lib which is Togl, an OpenGL add-on widget to Tcl/Tk. Unfortunately the mailing list does not seem active, because: The first env command responds C compiler cannot create executables and refers me to the config.log. That has a few lines showing the -mno-cygwin flag has been removed and telling me to use a mingw-targeted cross-compiler. Not sure if those are warnings or that is why later what looks to be a hello- world-like little C compile reports failure leading next to the cannot create exes message. Googling did turn up a long-ago discussion mentioning deprecating no-mingw (and to my relief that this is not something poor know-nothings like me should encounter) but the obvious solution (a mingw-targeted cross-compiler) did not work out two ways: 1. Just googling that did not cause anything to jump out at me. 2. I am wondering if this is a cross-compiler situaton, since I am on Windows trying to build a windows DLL. Any clues greatly appreciated! kt -- 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
find utils (updatedb) crashes on invalid win symlink
Some time ago, my daily updatedb stopped working and I just got around to figuring out why -- it was dying with (I wish I had the message, but I lost it) an internal error in 'find' which would then exit and updatedb would overwrite the old file with a new empty file. But the place where it died was where, in the root dir, I had a symlinkD pointing to a no-longer existing drive. Used to have a network drive L:, in order for updatedb to index it (reliably), I created a windows symlink to it in root: l == L:. Later the network drive was no longer needed at L and was removed, but the symlink was left behind. find really didn't like that dangling symlink. Removed it (using windows, as cygwin doesn't seem able to remove symlinkD's). I think that thought cygwin understands windows symlinks as symlinks, it doesn't 'grok' the 'symlinkD' type links to directories (that explorer 'needs' to see them as a directory). I'm not sure, but I think symlinkD's are real directories with a file in them that points to the target. -linda -- 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: old install instructions? -mnomingw being removed?
On 1/2/2010 07:52, Ken Tilton wrote: Sorry, I am a complete noob to all this make/install/gcc stuff, I am just trying to make a fresh build of a DLL I have used for years to see if it resolves a problem. I installed cygwin 1.7.1 today on a windows 7 laptop. The directions for my library are great: VER=8.4.12 SRCDIR=`pwd` cd $SRCDIR/tcl$VER/win env 'CC=gcc -mno-cygwin' ./configure --enable-threads make libtclstub84.a cd $SRCDIR/tk$VER/win env 'CC=gcc -mno-cygwin' ./configure --enable-threads make libtkstub84.a cd $SRCDIR/Togl env 'CC=gcc -mno-cygwin' ./configure --with-tcl=../tcl$VER/win --with- tk=../tk$VER/win make That's from doc for the lib which is Togl, an OpenGL add-on widget to Tcl/Tk. Unfortunately the mailing list does not seem active, because: The first env command responds C compiler cannot create executables and refers me to the config.log. That has a few lines showing the -mno-cygwin flag has been removed and telling me to use a mingw-targeted cross-compiler. Not sure if those are warnings or that is why later what looks to be a hello- world-like little C compile reports failure leading next to the cannot create exes message. Googling did turn up a long-ago discussion mentioning deprecating no-mingw (and to my relief that this is not something poor know-nothings like me should encounter) but the obvious solution (a mingw-targeted cross-compiler) did not work out two ways: 1. Just googling that did not cause anything to jump out at me. 2. I am wondering if this is a cross-compiler situaton, since I am on Windows trying to build a windows DLL. Any clues greatly appreciated! kt Hi, The -mno-cygwin option has been removed from gcc4. If you need it, install the gcc-mingw package via the Cygwin setup, and use CC=gcc-3 -mno-cygwin instead. It is an older version of GCC, but it will get you somewhere. Yes, it is a cross-compile situation. MinGW and Cygwin are considered different hosts even if both are running on Windows. Cygwin programs use cygwin1.dll while MinGW programs use msvcrt.dll. -- 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
using a serial port with cygwin
Ive been reading up on this and I think I have a handle on knowing that I can use comx in cygwin or maybe /dev/ttySx with my usb-serial adapter. heres my problem, some of the docs I read are old and they refer to apps no longer with cygwin setup. so my question is what apps are available from setup that allow serial communication via a windows usb-serial adapter -- 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: Help on configuring keyboard on Cygwin/x on Windows XP
2010/1/1 Gunnar Vestergaard: I prefer that Emacs accepts input from my Faroese keyboard, or at least Danish if need be. Whatever I do, the US keyboard mapping is in effect always. How do I change that? I mean, for every X11 application? X questions should go to the cygwin-xfree list. The X server has autodetection for a number of Windows keyboard layouts for which it selects the corresponding X keyboard layout, but presumably Faroese (abbreviated 'fo') isn't among them. Hence you need to tell the X server yourself, using either the -xkblayout option at server startup: $ xwin -xkblayout fo Or the setxkbmap command for a running server: $ setxkbmap fo Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: it works well
now it doesn't complains.
thank you sincerely.
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote in
message news:20100101191658.ga32...@ednor.casa.cgf.cx...
On Thu, Dec 31, 2009 at 11:25:53AM -0500, Christopher Faylor wrote:
On Thu, Dec 31, 2009 at 05:00:25PM +0900, jojelino wrote:
hi
here is testcase to reproduce the problem
#include stdio.h
#include assert.h
int main(int argc, char**argv)
{
printf(argv %s,argv[1]);
open(argv[1],r);
assert(fp);
return 0;
}
build
make .txt in directory.
and run in cmd.exe
type,
a .txt
and it complains file can't be opened.
and you can see argv[1] is passed with preserved quote () although it
is
invoked in winshell
it must be eliminted when it is transduced to cygwin environment.
I don't see preserved quotes but I do see that ARGV has apparently been
changed to UTF-8 and is represented as: --.txt
Try setting LANG to something appropriate in your MS-DOS session and see
if that makes things work better.
I think I've fixed this problem in the upcoming cygwin snapshot at:
http://cygwin.com/snapshots/
if you want to give it a try. It will be in *today's* snapshot, not the
one from 12/29.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
