Re: gcc4: next release (Dave Korn we need you)
On Jul 7 18:24, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 06:12:23PM -0400, Charles Wilson wrote: On 7/7/2010 5:03 PM, Christopher Faylor wrote: or as a cross-compiler. Huh? Do you mean that we use cygwin's gcc as a code generator, and turn off everything that makes it cygwin: I mean that *I* build the DLL with a cross compiler based on the released version of gcc. Yes, me too. I hate to say that but it is faster than building on Cygwin... [...] Whether we use w32api in the cygwin tree or from somewhere else really doesn't matter as long as Cygwin builds. That's why I'd like to know if Cygwin builds with w32api from the mingw64 project. Even after a night's sleep I still don't like the idea to hvae two versions of w32api in the distro. To me, w32api belongs into /usr/include. One version for everybody. w32api is *not* cross compiler specific, it's a resource for all three targets, Cygwin as well as 32 bit and 64 bit Mingw. However, I won't object against having a version for the 64 bit gcc hidden in the cross-compiler tree, if there's no way around it. But *if* there's a way to keep just a single version, it should be exploited. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
On Jul 7 21:17, Charles Wilson wrote: On 7/7/2010 8:39 AM, Corinna Vinschen wrote: On Jul 7 08:08, Charles Wilson wrote: I hope I have summed up the various competing proposals fairly, and that this edition of my patented War and Peace emails helps move the discussion along to a conclusion. Ok, I'm sufficiently confused now. So, here are a few questions. - Why do we need two different mingw's again? What are the merits of having mingw32 *and* mingw64-32? mingw32 and mingw64-32 are different. [...] Ok, I'm not sure I get all this. I have no objections against having three mingw cross compilers, provided they are sufficently kept separate. I'm sure you guys will create the best possible solution here. I also do not care for the mingw headers and libs (mingw-runtime) which could or should be kept in the same tree as the cross compilers. I do care for w32api, but that's already in another mail... Corinna
Re: gcc4: next release (Dave Korn we need you)
On 7/8/2010 3:22 AM, Corinna Vinschen wrote: On Jul 7 18:24, Christopher Faylor wrote: [...] Whether we use w32api in the cygwin tree or from somewhere else really doesn't matter as long as Cygwin builds. That's why I'd like to know if Cygwin builds with w32api from the mingw64 project. Have you checked with Red Hat's lawyers concerning the use of mingw64's w32api to build their cygwin-based products? Even after a night's sleep I still don't like the idea to hvae two versions of w32api in the distro. To me, w32api belongs into /usr/include. One version for everybody. w32api is *not* cross compiler specific, it's a resource for all three targets, Cygwin as well as 32 bit and 64 bit Mingw. Well, the 64bit build of w32api provides over 2000 import libraries. The 32bit build has only about 225. Apparently this is because the .def files that each are generated from are maintained separately, vetted on each system, and their contents *differ* on each system. Until recently, mingw64 focused mainly on 64bit support; 32bit efforts are much younger for them. So while the include/ bits may be the same for mingw64's w32api between 32bit and 64bit systems, the lib/ bits definitely differ. And, of course, they differ from the current cygwin/mingw.org 32bit version -- but that's a lot easier to fix than the headers IMO. (.def file contents don't appear to be as difficult to share between mingw64 and mingw.org, as far as this non-lawyer can tell. I mean, it's not like anybody could copy the .def file contents from the Windows SDK, so mingw.org doesn't need to worry about that). However, I won't object against having a version for the 64 bit gcc hidden in the cross-compiler tree, if there's no way around it. But *if* there's a way to keep just a single version, it should be exploited. I don't get this. There are three reasons to be concerned about multiple copies -- even if they are identical (which in this case they are not and can't be, esp. 64bit vs 32bit implibs). 1) disk space 2) things that should be identical (like headers for the OS's API) out of sync, or keeping them deliberately different 3) end user confusion IMO (1) is a non-issue. If you're going to install a cross compiler, some duplicated implibs and headers are the least of your concerns with regards to disk space. (2) -- well, if cygwin/Red Hat doesn't care about the where did you get that function declaration you mingw64 folks added to foo.h problem, then maybe the mingw64 w32api headers can be used by all of (mingw64-32bit, mingw64-64bit, mingw.org-32bit, cygwin) compilers. But the implibs will be distinct between the 64bit version and the 32bit version(s). But...even given that, I still don't see a real problem. Do we worry, when creating a sysroot for an embedded target on a linux $host, when compiling zlib, that we have two copies of zlib.h -- one in /usr/include, and another in /usr/my-embedded-toolchain/sysroot/usr/include? Do we worry that there are multiple copies of the glibc headers in both locations (or all of them, if I have several cross compilers)? Even when I'm using exactly the same version of glibc or zlib on both my development machine and the target, so the headers are, in fact, identical? No...that's just how cross compilers work! The sysroot for cross-compiler target A will probably contain lots of similar stuff, maybe even identical, to the sysroot for cross compiler target B, and similar to the stuff in the $host's sysroot /. (3) I think it's is hell of lot MORE confusing for our users, for us to foist a regime on them that says cross compilers should never access stuff in the system include or lib directories; that's cross-compiler 101. Except, of course, for /usr/include/w32api and /usr/lib/w32api -- and we've either patched all of our mingw* cross compilers to look there automatically behind your back in addition to its own sysroot, or you are expected to manually add the appropriate and completely non-intuitive -L/usr/lib/w32api -I/usr/include/w32api to your CROSS CPPFLAGS/LDFLAGS when building. Except for 64bit, where you should use -I/usr/include/w32api but not -L/usr/include/w32api. And never mind that that is completely DIFFERENT than how the same cross compiler toolchain would operate over on any other $host, so we get FAQs not just from total n00bs but also from people with lots of experience using linux-$hosted cross compilers. Ugh! And that's not even going into the issue of how, exactly, we are to 'tease out' the w32api-related PARTS of mingw64's separate mingw64-crt-include and mingw64-crt-lib trees, if we plan to share mingw64's w32api between cygwin|mingw.org, and mingw64-32, but (obviously) not the crt/mingw-runtime bits, as mingw64 has them all jumbled together. AND assuming you, and Red Hat, have no legal issues related to mingw64's w32api headers + cygwin. It'd be great if those legal concerns ARE unimportant, don't get me wrong. But I'd rather have a
Re: gcc4: next release
On 07/07/2010 02:47, JonY wrote: Hello, Can I ask what will be the next version of GCC be in Cygwin? 4.5.0-1 if I'm snappy. 4.5.1-1 if I'm not. I plan to get back to it at the start of next week. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Locale data is also conflicting. Yaakov suggested that I sync up with Cygwin GCC so the clash won't be so problematic, eg 4.5.0 Cygwin with 4.5.1 branch snapshot for mingw-w64. GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying to avoid breaking user's self-built packages, so 4.5.0 and earlier is out of the question. The current 4.3.4 is too old for mingw-w64. Going with 4.5.1 seems the simplest solution. I'm slightly astonished though! How on earth did you manage to swing permission to put an ABI-breaking backwardly-incompatible change on a release branch? cheers, DaveK (still catching up with the backlog - I haven't finished reading this thread yet...)
Re: [ITP] mingw-w64
On 05/07/2010 18:38, Charles Wilson wrote: However, the DLLs don't appear to be in the correct locations. opt/mingw64/bin/libobjc-2.dll opt/mingw64/bin32/libgcc_s_sjlj-1.dll opt/mingw64/bin64/libgcc_s_sjlj-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/32/libstdc++-6.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgfortran-3.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libgomp-1.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libssp-0.dll opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.6.0/libstdc++-6.dll Now, the DLLs buried down in the 4.6.0/ directory I can see (it appears to be a mistake, but that IS where they normally go...even if we choose to put them in toplevel bin32 and bin64 dirs instead.) It looks like the cygport is missing some 'mv' commands. Should be handled by passing -bindir=$bindir to libtool rather than mv'ing them after make install. But how the heck did libobjc-2.dll get into the regular bin/ dir? And why is there only one version of it? I forgot about libobjc when adding -bindir support to GCC(*, didn't make it in time for 4.5 branch. Guess I should see about backporting that for 4.5.1. cheers, DaveK -- (*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445#c3
Re: [ITP] mingw-w64
On 06/07/2010 16:59, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I haven't really checked, but I think that may no longer be true since the
upgrade to 2.64/1.11.1.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
If you look at the distro gcc4 cygport, you'll see it carefully does just
the necessary amount of autoconfing and automakeing. (But that may no longer
be necessary, as I mentioned above.)
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
I'm switching to this approach for gcc-4.5.0-1, anyway.
cheers,
DaveK
Re: gcc4: next release
On 07/07/2010 02:47, JonY wrote: I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything cygwin gets installed to /usr, however, with gcc 4.6, the locales data clashes. Yaakov suggested installing to /usr, but there are some problems with it. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Hmm, does this even happen when it is being built as a cross- rather than native- compiler? That would be a GCC bug if so; cross-compilers are meant not to look in the standard system directories as if they were native, see the docs for LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR, STANDARD_INCLUDE_DIR and INCLUDE_DEFAULTS(*) for full details. Locale data is also conflicting. So can't it just go in $prefix/$target/share instead of $prefix/share after a bit of fiddling with configure options? cheers, DaveK -- (*) - http://gcc.gnu.org/onlinedocs/gccint/Driver.html
[RFU] vorbis-tools 1.4.0-1
Please leave 1.2.0-2 as previous. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/vorbis-tools/vorbis-tools-1.4.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/vorbis-tools/vorbis-tools-1.4.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/vorbis-tools/setup.hint -- David Rothenberger daver...@acm.org
Re: gcc4: next release (Dave Korn we need you)
On Thu, Jul 8, 2010 at 8:25 AM, Charles Wilson cyg...@cwilson.fastmail.fm wrote: Well, the 64bit build of w32api provides over 2000 import libraries. The 32bit build has only about 225. Apparently this is because the .def files that each are generated from are maintained separately, vetted on each system, and their contents *differ* on each system. Until recently, mingw64 focused mainly on 64bit support; 32bit efforts are much younger for them. So while the include/ bits may be the same for mingw64's w32api between 32bit and 64bit systems, the lib/ bits definitely differ. Just to clarify, we've had 32-bit support for a very long time, almost since the beginning. And, there are far fewer imports because there are far fewer libs to import by default.
Re: gcc4: next release
On Thu, Jul 8, 2010 at 12:08 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying to avoid breaking user's self-built packages, so 4.5.0 and earlier is out of the question. The current 4.3.4 is too old for mingw-w64. Going with 4.5.1 seems the simplest solution. I'm slightly astonished though! How on earth did you manage to swing permission to put an ABI-breaking backwardly-incompatible change on a release branch? 4.5.x ABI and 4.6.x ABI are what differ, not 4.5.0 and 4.5.1. There's no point in making the first shipped compiler have an ABI that's already been changed. Hence 4.6.
Bug: XTerm scrollbar issue
The issue is documented in xterm's INSTALL file. Packagers have to essentially ensure that the prototype for XawScrollbarSetThumb is compiled properly. For instance, the package for xterm in Debian uses --enable-narrowproto That turns on a #define for NARROWPROTO which may be missing (or not not coordinated with Xfuncproto.h, which in turn sets #defines used in Xaw, to choose between a float and a double for the type of one of its parameters). Changing subject to reflect that this is a bug with the Cygwin XTerm package. -- 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/
Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
I don't know if this is the right place to ask this question, but if it is not please advise me where to send it. Midnight Commander exits with F10, and in a native bash window or rxvt F10 exits to the last directory viewed. In an xterm though, it exits to the original directory from which MC was started. Do you think this a bug in MC or is it WAD? If you think it's a bug in MC I will gladly debug it myself, I just want to know if it's WAD for xterm's first. I am using a fresh cygwin + cygwin/X install on WinXP SP3, and I will supply the usual problem report documentation if needed to answer my question. Regards, Peter -- 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: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
On 7/8/2010 10:35 PM, Peter Farley wrote: I don't know if this is the right place to ask this question, but if it is not please advise me where to send it. Midnight Commander exits with F10, and in a native bash window or rxvt F10 exits to the last directory viewed. In an xterm though, it exits to the original directory from which MC was started. Do you think this a bug in MC or is it WAD? If you think it's a bug in MC I will gladly debug it myself, I just want to know if it's WAD for xterm's first. I am using a fresh cygwin + cygwin/X install on WinXP SP3, and I will supply the usual problem report documentation if needed to answer my question. Sorry, I don't know anything about MC really but isn't there some doc on it that describes what F10 is supposed to do? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/w32api/include/gdiplus
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-07-08 23:09:30 src/winsup/w32api/include/gdiplus Update of /cvs/src/src/winsup/w32api/include/gdiplus In directory sourceware.org:/tmp/cvs-serv26834/gdiplus Log Message: Directory /cvs/src/src/winsup/w32api/include/gdiplus added to the repository
src/winsup/w32api lib/Makefile.in lib/test.c C ...
CVSROOT:/cvs/src Module name:src Changes by: ironh...@sourceware.org 2010-07-08 23:14:54 Modified files: winsup/w32api/lib: Makefile.in test.c winsup/w32api : ChangeLog Added files: winsup/w32api/include/gdiplus: gdiplus.h gdiplusbase.h gdiplusbrush.h gdipluscolor.h gdipluscolormatrix.h gdipluseffects.h gdiplusenums.h gdiplusflat.h gdiplusgpstubs.h gdiplusgraphics.h gdiplusheaders.h gdiplusimageattributes.h gdiplusimagecodec.h gdiplusimaging.h gdiplusimpl.h gdiplusinit.h gdipluslinecaps.h gdiplusmatrix.h gdiplusmem.h gdiplusmetafile.h gdiplusmetaheader.h gdipluspath.h gdipluspen.h gdipluspixelformats.h gdiplusstringformat.h gdiplustypes.h winsup/w32api/include: gdiplus.h winsup/w32api/lib: gdiplus.c gdiplus.def Log message: 2010-07-08 Markus Koenig bas...@users.sourceforge.net * include/gdiplus.h: New file. * include/gdiplus/gdiplus.h: New file. * include/gdiplus/gdiplusbase.h: New file. * include/gdiplus/gdiplusbrush.h: New file. * include/gdiplus/gdipluscolor.h: New file. * include/gdiplus/gdipluscolormatrix.h: New file. * include/gdiplus/gdipluseffects.h: New file. * include/gdiplus/gdiplusenums.h: New file. * include/gdiplus/gdiplusflat.h: New file. * include/gdiplus/gdiplusgpstubs.h: New file. * include/gdiplus/gdiplusgraphics.h: New file. * include/gdiplus/gdiplusheaders.h: New file. * include/gdiplus/gdiplusimageattributes.h: New file. * include/gdiplus/gdiplusimagecodec.h: New file. * include/gdiplus/gdiplusimaging.h: New file. * include/gdiplus/gdiplusimpl.h: New file. * include/gdiplus/gdiplusinit.h: New file. * include/gdiplus/gdipluslinecaps.h: New file. * include/gdiplus/gdiplusmatrix.h: New file. * include/gdiplus/gdiplusmem.h: New file. * include/gdiplus/gdiplusmetafile.h: New file. * include/gdiplus/gdiplusmetaheader.h: New file. * include/gdiplus/gdipluspath.h: New file. * include/gdiplus/gdipluspen.h: New file. * include/gdiplus/gdipluspixelformats.h: New file. * include/gdiplus/gdiplusstringformat.h: New file. * include/gdiplus/gdiplustypes.h: New file. * lib/gdiplus.c: New file containing GDI+ variable definitions and GUIDs. * lib/gdiplus.def: New file. * lib/Makefile.in: Add gdiplus.o to EXTRA_OBJS, add gdiplus.c to SOURCES. * lib/test.c: Include gdiplus.h. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplus.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusbase.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusbrush.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdipluscolor.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdipluscolormatrix.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdipluseffects.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusenums.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusflat.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusgpstubs.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusgraphics.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusheaders.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusimageattributes.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusimagecodec.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/gdiplus/gdiplusimaging.h.diff?cvsroot=srcr1=NONEr2=1.1
Re: 1.7.5: running in a non cygwin command prompt
Am 08.07.2010 03:30, schrieb Shalomov, Inessa A (US SSA): I am trying to get the system() call working in my driver which I am running in a DOS terminal. For the sake of not porting out all of cygwin libraries and executables, I am trying to narrow down to a set of dll's and exe's required for my driver and only include those in my path. What I have gathered so far with the help of cygcheck is that I will need cyggcc_s-1.dll, cygiconv-2.dll, cygintl-8.dll, cygncurses-9.dll, cygreadline7.dll, cygwin1.dll, and sh.exe since system() executes the given command in a shell. My questions are as follows: 1) What .dll's and/or .exe's am I missing to be able to run the driver in a non cygwin command prompt? 2) Is it possible to run my driver (see below) in a non-cygwin prompt with a reduced set of cygwin dll's and .exe's? 3) If the system() call doesn't work when used in a non-cygwin environment, is there a windows native system() equivalent call I can use? ... My suggestion: * Drop the dependency on sh.exe by using one of the exec() calls rather than system(). * Apply static linking: gcc -static -static-libgcc ..., so you'll only need cygwin1.dll -- Thomas -- 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
Disable recycle bin for rm command
Hi! I see that the rm command uses the recycle bin to remove files. On What's new and what changed in Cygwin 1.7 - File Access related changes (http://cygwin.com/cygwin-ug-net/ov-new1.7.html#ov-new1.7-file) I read unlink(2) and rmdir(2) try very hard to remove files/directories even if they are currently accessed or locked. This is done by utilizing the hidden recycle bin directories and marking the files for deletion. I was testing this functionality on Win2k8 and figured out that rm uses recycle bin even the recycle bin is disabled for specific partition. Such behavior does not fit the restrictions I have on my system. Is there any way to disable this recycle bin functionality so the rm works like before this change? It would also be a nice feature that Cygwin respects the Recycle bin settings in case it is disabled. I was checking the FAQ and mailing list archives and I could not find the answer. TIA, Urban -- 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
^M problem in porting unix programs to window
Hi, there I am porting a unix project to windows via cygwin. make tool and perl script are used. The perl script file is called in a makefile to create some directories and move some files. All directory names written in the makefile are edited by emacs under linux, as well as the makefile. So I believe there is no ctrl-M in the files. But when I run make under cygwin, all directories are appended with ctrl-M, like /c/1/2/3^M, where the path of /1/2 is made by make. The perl file is called with /c/1/2/3 as a path argument by the makefile. I print out the value of the path variable before and after calling the perl script, and there is no ctrl-M. Also, I print out the value of path argument in the perl file, but ctrl-M comes up. I suspected that it might be caused by bash shell, so I repeated the procedure using tcsh. The problem still existed. In all, the development environment includes cygwin, make, perl, and bash or tcsh shell. All are installed with cygwin setup. If someone has experience with it, please advise me. Thanks a lot. -- View this message in context: http://old.nabble.com/%5EM-problem-in-porting-unix-programs-to-window-tp29104357p29104357.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ^M problem in porting unix programs to window
Please never mind. ctrl-M is caught. In fact, it lies in makefile. when the path is transferred to perl, ctrl-M is treated as a part of path name. ke...@ca wrote: Hi, there I am porting a unix project to windows via cygwin. make tool and perl script are used. The perl script file is called in a makefile to create some directories and move some files. All directory names written in the makefile are edited by emacs under linux, as well as the makefile. So I believe there is no ctrl-M in the files. But when I run make under cygwin, all directories are appended with ctrl-M, like /c/1/2/3^M, where the path of /1/2 is made by make. The perl file is called with /c/1/2/3 as a path argument by the makefile. I print out the value of the path variable before and after calling the perl script, and there is no ctrl-M. Also, I print out the value of path argument in the perl file, but ctrl-M comes up. I suspected that it might be caused by bash shell, so I repeated the procedure using tcsh. The problem still existed. In all, the development environment includes cygwin, make, perl, and bash or tcsh shell. All are installed with cygwin setup. If someone has experience with it, please advise me. Thanks a lot. -- View this message in context: http://old.nabble.com/%5EM-problem-in-porting-unix-programs-to-window-tp29104357p29105204.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug report: procmail hangs on large messages.
Hi, I have a problem with cygwin and procmail. If messages exceed a certain size, procmail just hangs, eating 100% cpu without doing anything. I've been trying to debug this further, but it just hangs, even with an empty .procmailrc file. Funny enough if I run procmail from within strace it runs fine, even with larger messages. I'm at a loss how provide you with more info about this problem. I binary-searched for the cutoff-point: Does not work: 8573458 bytes. Does work: 8573457 bytes. that is hex 0x82D212, nothing that i recognize... It appears to depend on total filesize independant of the headers to body ratio. Please help. CU, Sec P.S.: procmail -v says its: procmail v3.22 2001/09/10 cygwin says its procmail-3.22-10 -- Ok, we're making progress. I found a major bug (that Julian is committing now). -- Matthew Dillow on freebsd-chat -- 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
gcc4: throwing exception from signal handler
I would like to be able to catch certain signals (SIGSEGV and SIGSYS) and
throw a C++ exception (to be caught in a try/catch construct). As a simple
example:
#include stdio.h
#include string.h
#include stdexcept
#include signal.h
void throw_signal( int signum )
{
// fprintf(stderr,throw_signal: before throw;
signum=%d\n,signum);fflush(stderr);
throw std::runtime_error (throw_signal);
}
int main() {
struct sigaction new_action, d_old_action;
memset (new_action, 0, sizeof (new_action));
new_action.sa_handler = throw_signal;
sigemptyset (new_action.sa_mask);
new_action.sa_flags = 0;
if (sigaction (SIGSEGV, new_action, d_old_action) 0){
perror (sigaction (install new));
throw std::runtime_error (sigaction);
}
try {
int j = *((int *)NULL);
}
catch (...){
printf(caught exception\n);
}
}
g++ 3.3.4 gives the result I expect:
$ sh /usr/bin/set-gcc-default-3.sh
$ gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -fnon-call-exceptions throw_segv.cc
$ ./a.exe
caught exception
but g++ 4.3.4 aborts after the exception is thrown and before it is caught:
$ sh /usr/bin/set-gcc-default-4.sh
$ gcc --version
gcc (GCC) 4.3.4 20090804 (release) 1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -fnon-call-exceptions throw_segv.cc
$ ./a.exe
terminate called after throwing an instance of 'std::runtime_error'
what(): throw_signal
Aborted (core dumped)
Am I misunderstanding how this should work or doing something wrong? Or is
this a problem with Cygwin or gcc?
Thanks,
-- Don W.
cygcheck.out
Description: Binary data
throw_segv.cc
Description: Binary data
--
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: throwing exception from signal handler
On Thu, 8 Jul 2010 09:01:41 -0400, Don Ward wrote: I would like to be able to catch certain signals (SIGSEGV and SIGSYS) and throw a C++ exception (to be caught in a try/catch construct). As a simple example: [...] Am I misunderstanding how this should work or doing something wrong? Or is this a problem with Cygwin or gcc? I do not think that handling SIGSEGV with an exception is a good idea. Unless you get SIGSEGV as a result of some well thought through memory management games, at the point you get SIGSEGV your state is probably so foobar'd that trying to execute more code can only make it worse. It is pretty much unrecoverable condition. From diagnostic POV, getting a core dump with the error state seems better than anything you could do with the exception. I am not sure but I do not think that throwing exceptions from signal handlers is generally supported. Somebody will certainly correct me if I am wrong. -- VH -- 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
undefined reference to `QTextStream::QTextStream(__sFILE64*
Hello! I have the same problem as 10 May 2003 12:54:20 +0200 , written from Corinna Vinschen: I got the actual automoc4-Software from kdesupport, and try to ld with the qt for Windows. The Cygwin/usr/include/stdio.h make a definition of stderr at line 148 as: #define stderr (_REENT-_stderr) and got the error /cygdrive/y/Workspace/automoc/Debug/../src/kde4automoc.cpp:129: undefined reference to `QTextStream::QTextStream(__sFILE64*, QFlagsQIODevice::OpenModeFlag)' within eclipse This 64-bit-entry is not supplied by QtCore, only the 32-bit one. What is to do? Thanks for helping guy -- Forschungsinstitut Daimler AG Guy Maurel Postfach 2360 89013 Ulm Deutschland If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation. -- 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: ImageMagick SVG Problem
2010/7/3 t.a.n.s.t.a.a@comcast.net: Has anybody using ImageMagick noticed that 'display' and other ImageMagick tools are having trouble displaying SVG files? Most of the tools complained about missing files in the /usr/share/fonts/corefonts/ directory, so I created a symlink to /c/Windows/Fonts/ (in Win7 Crippled), and *most* SVG files containing text now function correctly. Good link. Which package should create this symlink in it's postinstall.sh? Maybe we need an empty msttcorefonts package which just creates this link and updates the fontcache. Do we need that or is it's ImageMagick's fault? I'm not so familiar with XWin. I only know about /usr/share/fonts/TTF/ and my /etc/fonts/fonts.conf does contain the $WINDOWS/Fonts dir, and my fontcache does contain the correct link for arial.ttf Is there some problem with the SVG format? My Debian 5.0 box handles SVG files OK, so it seems to be related to the platform, not the package. I can reproduce it. The error is: display: unable to read font `/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'' and so it looks like it is ImageMagick's fault, having --with-windows-font-dir=/usr/share/fonts/corefonts as its configure arg. and not usr/share/fonts/TTF/ or such. I'll fix the wrong prefix at least. And I'll prepare a new package ASAP, since I did the last for Volker Q. and Yakoov already pinged two times for relevant upstream fixes. Note that I'm not really interested in maintaining this package, but as long as no one else cares, I'll do. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.5: Extra \r when redirecting output
I'm seeing the following behavior in 1.7.5 and also 1.5.25, but not in 1.3.12 (yes, we still use that version). On a text mode mount, we have the file foo which has \r\n line endings. If I do grep -i line foo|od -cd then the output shows proper \r\n line endings. However, if I do grep -i line foo foo.out od -cd foo.out then the line endings are \r\r\n. See attached files. This works fine on binary mounts. Thanks, Dave foo.out Description: foo.out foo Description: foo -- 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
Another cygcheck issue?
When I run 'cygcheck' on my vista 64b system, I always get a bunch of error messages on stderror. To wit: $ cygcheck -cvs|e_capa /tmp/e_capa_4800-oa # from my 'e_capa' script /bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5 Access is denied. /bin/cygrunsrv: warning: OpenService failed for 'odserv': Win32 error 5 Access is denied. /bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5 Access is denied. /bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5 Access is denied. /bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5 Access is denied. /bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5 Access is denied. /bin/cygrunsrv: warning: OpenService failed for 'WPFFontCache_v0400': Win32 error 5 Access is denied. Warum? Lee -- 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 installing libxml
Hi Folks, I have the problem to install libxml. Alter Starting setup as admin I proceed to the selection of the download, select the mirror http://cygwin.mirrors.hoobly.com. Enter libxml under Search and found libxml in the Gnome folder. When I select the first libxml the setup crashes How can I install libxml? I need the libxml to compile xml2. Thanks for any help Franz -- IMPORTANT I will read replies only from the mailing list. If you send me email directly it will be deleted. GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- 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: throwing exception from signal handler
Václav Haismam wrote: On Thu, 8 Jul 2010 09:01:41 -0400, Don Ward wrote: I would like to be able to catch certain signals (SIGSEGV and SIGSYS) and throw a C++ exception (to be caught in a try/catch construct). As a simple example: [...] Am I misunderstanding how this should work or doing something wrong? Or is this a problem with Cygwin or gcc? I do not think that handling SIGSEGV with an exception is a good idea. I agree, in general. Unless you get SIGSEGV as a result of some well thought through memory management games But that is what I am doing. I also want to catch SIGSYS to determine whether shmat() is available when we don't know in advance whether cygserver is running. In either case, if the signal is generated I want to catch it and try something else. In these contexts I want to treat SIGSEGV and SIGSYS as non-fatal error returns. . . . I am not sure but I do not think that throwing exceptions from signal handlers is generally supported. It appears that is what the -fnon-call-exceptions is for. From the gcc-4.3.5 manual: -fnon-call-exceptions: Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does not exist everywhere. I guess one question is whether the runtime support exists in Cygwin 1.7 with gcc 4.3.4. -- Don W. -- 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: cygport cross compile(r) support [was: Re: cygport patch: suppress libtool fixup step]
On 7/7/2010 11:39 PM, Yaakov (Cygwin/X) wrote: On Wed, 2010-07-07 at 22:16 -0400, Charles Wilson wrote: Hmm. That's what I *was* doing: JonY's -src provides a cygport that I didn't mean the .cygport(5), I meant cygport(1). The goal is to make these workarounds unnecessary. Sure. There's three status levels of cygport support for any desired behavior: 1) no way to coerce cygport(1) to do what you need without patching cygport(1) itself 2) odd workarounds in .cygport(5) can make cygport(1) do what you need 3) every thing works nice and cleanly No question, we're at (1) right now. With my two small patches, we can be at (2). It'll take more work -- and different and more complex solutions -- to move from (1) all the way to (3). Honestly, I just don't get this. Are you participating in a live #mingw-w64 session, or looking at old logs? Live; I've been there since yesterday. Hmm. The mingw64-gcc I *just built* /is/ multilib, ... So, it *does* build. ... JonY and I both built it. Hence my confusion. Then I'm missing something, because the packages I grabbed from sourceforge didn't build multilib, and I was told that additional patches were necessary. Well, NightStrike said in another thread that many of the #chat folks had complained that it was a difficult and error prone process in general, but that JonY has gone through and documented all of the necessary steps, and his .cygport(5) implements those steps, so... I agree (willing to be persuaded that all three compilers could be NON-multilib, but it seems JonY *wants* to provide multilib -- I guess for just the default-to-64bit compiler -- and I'm not gonna stand in his way, if he'd doing the work. I don't mind if it's not multilib, it would certainly make things easier. Unless Corinna/cgf really put their foot down and forbid multilib, I think we should defer to whatever JonY wants to do. Now, his ORIGINAL proposal was 64bit only, non-multilib. Maybe he'd be pleased to go back to that; my feeling is he'd rather do multilib if possible, but I'm not sure, and certainly don't speak for him. But the difference is, we are NOT actually talking about two completely separate platforms. You CAN run mingw apps and use mingw DLLs from cygwin directly (mingw64-32, or mingw.org), because it's running on top of plain old windows. Ditto mingw64-64 -- assuming you're on a 64bit Windows. I still believe that within the context of Cygwin, that mingw* is no different than any other cross-compiler. This is an important distinction when we talk about runtime data (more on that below). Yes... And...libtool already makes allowances for this: that's why cygwin specifically uses the 'cyg' prefix for all DLLs, so they won't conflict with mingw libs that could be in use simultaneously on the same machine (*). And I won't mention how many problems the 'cyg' prefix has *caused*. That is true. However, you weren't around before its introduction, back in the bad old days where building DLLs at all on cygwin and mingw was extremely difficult, and required massive internal patching (no autoimport support, and nobody in the free software economy had existing support for MSVC). What's worse, is every Tom Dick and Harry would create their own (native w32) DLL versions of software, all with slightly different mechanisms and subtly distinct APIs -- and all named libz.dll or libtiff.dll. This caused all kinds of heck when your cygwin program picked up NCSA netscape's libjpeg.dll by mistake. The cyg prefix -- for all the trouble it causes in dlopen() scenarios -- is a godsend for the much-more-common non-dlopen cases. We are unaffected by any native DLL hell episodes... I would REALLY like to be able to set $PATH to include /usr/sysroot/mingw32/bin and test (for example) mingw-bzip2.exe WITHOUT having to go manually copy /usr/sysroot/mingw32/lib/libbz2_2.dll, /usr/lib/gcc/i686-pc-mingw32/4.6.0/libgcc_s-1.dll to /usr/sysroot/mingw32/bin/ before I can! (And then, have to remember to redo that every time something gets updated in its proper buried location). The (sole?) purpose of /usr/$target/bin is to contain binutils' cross-tools. WAIT. When did I say /usr/$target/bin? I never said that. I said /usr/sysroot/$target-shortname/bin And I'm not even sure that THIS sysroot tree should be the same as the one you may (or may not) pass to gcc's configure with --sysroot. It's just: the place where non-toolchain packages that are compiled using a particular cross compiler will go. E.g. you'd configure mingw-zlib with --prefix=/usr/sysroot/mingw32. /usr/sysroot/ as a literal string, not a virtual placeholder that means /usr/$target. This so-called sysroot is DIFFERENT than /usr/$target/bin. Remember, here's the fedora-mingw filesystem that was the motivating idea: http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout [root] | +- etc | | | +- rpm | | | +-
Re: gcc4: throwing exception from signal handler
On 08/07/2010 14:01, Don Ward wrote: I would like to be able to catch certain signals (SIGSEGV and SIGSYS) and throw a C++ exception (to be caught in a try/catch construct). As a simple example: Am I misunderstanding how this should work or doing something wrong? Or is this a problem with Cygwin or gcc? Throwing exceptions from a signal handler is a can of worms that requires support from both the compiler and the C runtime. I was working on adding this support for the distro package of gcc-4.5 before I had to go AWOL a couple of weeks ago; it requires building the Cygwin DLL with EH tables, and adding support in the last-chance stack unwinder in libgcc that is able to unwind past our sigfe/sigbe stuff. I'll be back in the Cygwin/GCC world starting next week. 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: problem installing libxml
On 7/8/2010 9:47 AM, cygwin.20.maillingl...@spamgourmet.com wrote: Hi Folks, I have the problem to install libxml. Alter Starting setup as admin I proceed to the selection of the download, select the mirror http://cygwin.mirrors.hoobly.com. Enter libxml under Search and found libxml in the Gnome folder. When I select the first libxml the setup crashes How can I install libxml? I need the libxml to compile xml2. I already had this installed but reinstalling worked fine. Did you use the latest 'setup.exe' from cygwin.com? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Another cygcheck issue?
On 7/8/2010 9:43 AM, Lee D. Rothstein wrote: When I run 'cygcheck' on my vista 64b system, I always get a bunch of error messages on stderror. To wit: $ cygcheck -cvs|e_capa /tmp/e_capa_4800-oa # from my 'e_capa' script /bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5 Access is denied. It's in the name of Windows security. Try it again from a shell launched in a Window Run as administrator. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Bug report: procmail hangs on large messages.
Sec, On Thu, Jul 08, 2010 at 03:00:21PM +0200, Stefan `Sec` Zehl wrote: I have a problem with cygwin and procmail. If messages exceed a certain size, procmail just hangs, eating 100% cpu without doing anything. I've been trying to debug this further, but it just hangs, even with an empty .procmailrc file. Funny enough if I run procmail from within strace it runs fine, even with larger messages. I'm at a loss how provide you with more info about this problem. I binary-searched for the cutoff-point: Does not work: 8573458 bytes. Does work: 8573457 bytes. Sorry, but I cannot reproduce the above problem: $ wc -c big.mail 10001689 big.mail $ procmail big.mail $ Could this be a BLODA problem? http://cygwin.com/faq/faq.using.html#faq.using.bloda Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: throwing exception from signal handler
Dave Korn wrote: On 08/07/2010 14:01, Don Ward wrote: I would like to be able to catch certain signals (SIGSEGV and SIGSYS) and throw a C++ exception (to be caught in a try/catch construct). As a simple example: Am I misunderstanding how this should work or doing something wrong? Or is this a problem with Cygwin or gcc? Throwing exceptions from a signal handler is a can of worms that requires support from both the compiler and the C runtime. Understood! I was working on adding this support for the distro package of gcc-4.5 before I had to go AWOL a couple of weeks ago; it requires building the Cygwin DLL with EH tables, and adding support in the last-chance stack unwinder in libgcc that is able to unwind past our sigfe/sigbe stuff. I'm glad someone is (or will be) working on it. In the meanwhile, I can make do with gcc 3.4.4. Thanks, -- Don W. -- 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: cygport patch: suppress libtool fixup step
On 06/07/2010 19:56, Charles Wilson wrote: To deal with the duplicated DLLs from two different multilib mingw64 toolchains (one that supports -m32 and -m64, but *defaults* to -m64, and one that also supports -m32 and -m64, but *defaults* to -m32), the DLLs are actually installed into a completely different directory outside the $triple area. The 64bit dlls are moved manually to $special_prefix/bin64/ and $special_prefix/bin32 -- because these DLLs are shared by both toolchains in the specificed -mXX mode, so the deep directory inside one toolchain's private area or the other, are both inappropriate. In what way are these DLLs shared? They are target libraries, they aren't linked into the cross-compiler itself, and applications built by the cross-compiler don't link directly against the DLLs anyway, they have import libs. But...this is all handled manually, after 'make install'. I think it would be cleaner if the right -bindir settings were sent to libtool during the build/install process. This is PR40125(*), btw. Which I'm down to fix, I guess I'd better get on with it. cheers, DaveK -- (*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125 -- 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: throwing exception from signal handler
On 08/07/2010 18:02, Don Ward wrote: I'm glad someone is (or will be) working on it. In the meanwhile, I can make do with gcc 3.4.4. Yep, 3.4.4 uses old-style SJLJ exception handling, which can jump past anything without needing to understand it; you'll be good there, although it's not as fast as dwarf2 EH, but it ought to be reliable until we've got the newer one working. 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: Coping with large iso files for network-independent Cygwin installation
On 07/07/2010 09:29, Corinna Vinschen wrote: On Jul 7 08:03, Fergus wrote: Nevertheless, it is a tantalising problem: what's the best answer to give to a 3rd party who wants to install [1.7] on a machine without network access? Rsync the content of a mirror of your choice onto a stick. Copy setup.exe and setup-legacy.exe to the stick. On the target machine, start one of setup or setup-legacy, choose Install from Local Directory, enter the path to the stick, for instance X:\, as the Locale Package Directory. Install. Done. Just for completeness: You can also choose Install from Internet, and add your path as a User URL with the textbox and Add button at the bottom of the Choose A Download Site dialog. The difference is that doing it this way will create a local package repository on the machine you're installing to, should you want to have one for later when you might not have the USB stick around. 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: 'x' key not working in cygwin shell
On 07/07/2010 08:37, Csaba Raduly wrote: On Tue, Jul 6, 2010 at 9:59 PM, Christopher Faylor wrote: On Tue, Jul 06, 2010 at 07:41:03PM +, Peter Waltman wrote: This is a weird one. I just updated cygwin on my windows 7 machine, and now my 'x' (lowercase 'x') key isn't working. The key works outside of cygwin, and when I type the uppercase 'X' it works, but just not the lowercase. When I type a lowercase 'x', I get nothing. No idea where to start with that one. Any suggestions? To quit the window, I had to use the 'ctrl-d' key combo to shut it down. Sounds like your .inputrc file has CRLF line endings. That's some impressive psychic debugging. Care to you explain it? The impressive bit is that it's usually the 'e' key that fails when there are CRLF line endings in .inputrc, but he still nailed it in one despite this being a complaint about the letter 'x'! (As for the solution to the mystery, just see how many times it's come up in the archives down the years) 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: configure rxvt on cygwin 1.7.5
Andy Koppe a écrit : Setting termName to xterm in rxvt is a bad idea, because the two terminals diverge in various ways, for example regarding keycodes for modifier key combinations. Better stick with TERM=rxvt. ok Have a look at http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files to see which files are being sourced when bash is invoked with --login. I've together the contains of /etc/bashrc and ~/.bash into a single file ~/.profile and now it's ok for my prompt and aliases ! But I've still some problems with special characters (é à ç ...), how can I change default encoding to avoid errors like below : [phili...@port78]~/Documents $ ls cl* clé avast.txt [phili...@port78]~/Documents $ ls clé* ls: cannot access clé*: No such file or directory Thank's, Philippe. -- 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: next release
On 7/8/2010 1:09 PM, Dave Korn wrote: On 07/07/2010 02:47, JonY wrote: Locale data is also conflicting. So can't it just go in $prefix/$target/share instead of $prefix/share after a bit of fiddling with configure options? I believe it will be fine, if you use a custom --datarootdir settings (e.g. --datarootdir='$(prefix)/explicit-target-triple/share') There is some pushback against that idea, tho. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: configure rxvt on cygwin 1.7.5
On 7/8/2010 2:44 PM, philippe wrote: I've together the contains of /etc/bashrc and ~/.bash into a single file ~/.profile and now it's ok for my prompt and aliases ! But I've still some problems with special characters (é à ç ...), how can I change default encoding to avoid errors like below : [phili...@port78]~/Documents $ ls cl* clé avast.txt [phili...@port78]~/Documents $ ls clé* ls: cannot access clé*: No such file or directory You probably need to abandon rxvt and switch to either rxvt-unicode or mintty. Rxvt pretty much only supports ASCII characters. It's also abandoned upstream, so it isn't likely to be fixed either. However, if rxvt used to work for you under Cygwin 1.5, you might be able to make it happy again by changing your LANG setting to LANG=C. I highly recommend mintty. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygport patch: suppress libtool fixup step
On 7/8/2010 1:23 PM, Dave Korn wrote: On 06/07/2010 19:56, Charles Wilson wrote: To deal with the duplicated DLLs from two different multilib mingw64 toolchains (one that supports -m32 and -m64, but *defaults* to -m64, and one that also supports -m32 and -m64, but *defaults* to -m32), the DLLs are actually installed into a completely different directory outside the $triple area. The 64bit dlls are moved manually to $special_prefix/bin64/ and $special_prefix/bin32 -- because these DLLs are shared by both toolchains in the specificed -mXX mode, so the deep directory inside one toolchain's private area or the other, are both inappropriate. In what way are these DLLs shared? They are target libraries, they aren't linked into the cross-compiler itself, and applications built by the cross-compiler don't link directly against the DLLs anyway, they have import libs. I guess the term 'shared' is not exact. Rather, consider the following scenario: 1) There exists a mingw64-based gcc, that while defaulting to 64bit mode, is multilib and supports also -m32. When it is built, you will get two copies each of (e.g.) libstdc++-sjlj-6.dll, libstdc++.dll.a, libstdc++.a, and libstdc++.la. One of these sets will be 32bit, and the other will be 64bit. Now, the .la, .a, and .dll.a will all live in $prefix/lib/gcc/x86_64-w64-mingw32/VER/ for 64bit $prefix/lib/gcc/x86_64-w64-mingw32/VER/lib32 for 32bit since we usually build with --enable-version-specific-runtime. e.g. $(toolexeclibdir). This is as it should be. 2) Suppose there also exists a separate mingw64-based gcc. Only this one defaults to 32bit (it may or may not also be multilib and support -m64; that's unimportant here). When building this compiler, you will get a set of 32bit libs, libstdc++-sjlj-6.dll, libstdc++.dll.a, libstdc++.a, and libstdc++.la. (If it is multilib, you may also get another matching 64bit set). Now, in this case the .la, .a, and .dll.a will all live in $prefix/lib/gcc/i686-w64-mingw32/VER/ for 32bit $prefix/lib/gcc/i686-w64-mingw32/VER/lib64 for 64bit, if multilib since we usually build with --enable-version-specific-runtime. e.g. $(toolexeclibdir). This is as it should be. 3) Now, if we want to have a *single* consolidated location for the $target DLLs -- so that you can actually RUN the stuff you build, without a very odd set of $PATH settings -- where should those DLLs go? The original idea was that there would be a special /bin32 and /bin64 directory for them. This has since been refined to a custom sysroot a la' fedora: /usr/sysroot/mingw64-32/bin/ (A) /usr/sysroot/mingw64/bin/ (B) Into (A) would go all the DLLs that are 32bit: the ones from $prefix/lib/gcc/x86_64-w64-mingw32/VER/lib32 AND the ones from $prefix/lib/gcc/i686-w64-mingw32/VER/ Similarly, into (B) would go all the DLLs that are 64bit: the ones from $prefix/lib/gcc/x86_64-w64-mingw32/VER/ AND, if the nominally 32bit mingw64 compiler is also multilib, the ones from $prefix/lib/gcc/i686-w64-mingw32/VER/lib64 But...assuming the nominally 64bit but multilib mingw64 compiler, and the nominally 32bit (multilib?) compiler have the same version, then you will have TWO identical DLLs living at the same location. Our setup.exe doesn't allow this, and it's bound to cause issues. So the idea was that JonY would pick ONE of each pair as the blessed one, to be delivered in the (e.g.) mingw64-m32-libstdc++6-VER-REL.tar.bz2 package, and in the mingw64-m64-libstdc++6-VER-REL.tar.bz2 package. So, even though you have two compilers that might be thought to own that installation package, there is only one such package for each duplicated DLL, and that package is shared. But...this is all handled manually, after 'make install'. I think it would be cleaner if the right -bindir settings were sent to libtool during the build/install process. This is PR40125(*), btw. Which I'm down to fix, I guess I'd better get on with it. Well, yes...I agree with Doug Semler that by default, the -bindir argument should be $(toolexeclibdir) and not $(bindir) for cross builds. That would be nice and clean, and would be similar to how .so's are normally treated on linux IIRC. It also makes the most sense for $host=not-cygwin, $target=mingw* cross compilers. I'm just arguing that for the *specific* case where $host=cygwin and $target=mingw* (e.g. we know that the underlying platform ALSO supports running the target executables and DLLs), that as a cygport packaging step -- NOT part of gcc's own internal build or install process -- the DLLs should be plucked from $(toolexeclibdir) and put into a common location, which by *policy* on cygwin would be the $(special_prefix)/bin/ directory, where $(special_prefix) is the value that shall be passed as --prefix= when building cygwin-deployed packages whose contents are compiled using $host=cygwin, $target=mingw* cross
Re: gcc4: throwing exception from signal handler
On 7/8/2010 11:48 AM, Dave Korn wrote: I'll be back in the Cygwin/GCC world starting next week. YAY! We missed you, Dave. Welcome back! -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: configure rxvt on cygwin 1.7.5
Jeremy Bopp a écrit : [...] However, if rxvt used to work for you under Cygwin 1.5, you might be able to make it happy again by changing your LANG setting to LANG=C. No, i don't know where to modify this option LANG :-) I highly recommend mintty. ok, mintty is distributed with cygwin and seems to be a nice terminal. I've search a little about mintty configuration, i understand that i've to move ~/.profile to ~/.minttyrc, but it's not sufficient to traduce in a mintty syntax my ~/.Xdefault or the command below : rxvt -fn -*-Courier-medium-r-*-18-*-*-*-*-iso8859-1 -geometry 90x30 -sr -bg #d5 -fg black -sl 8000 -termName rxvt -e /usr/bin/bash --login -i Do you know a good tutorial to configure mintty or can you help me! Thank's, Philippe. -- 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: configure rxvt on cygwin 1.7.5
On Thu, Jul 8, 2010 at 4:22 PM, philippe wrote: Jeremy Bopp a écrit : [...] However, if rxvt used to work for you under Cygwin 1.5, you might be able to make it happy again by changing your LANG setting to LANG=C. No, i don't know where to modify this option LANG :-) I highly recommend mintty. ok, mintty is distributed with cygwin and seems to be a nice terminal. I've search a little about mintty configuration, i understand that i've to move ~/.profile to ~/.minttyrc, but it's not sufficient to traduce in a mintty syntax my ~/.Xdefault or the command below : rxvt -fn -*-Courier-medium-r-*-18-*-*-*-*-iso8859-1 -geometry 90x30 -sr -bg #d5 -fg black -sl 8000 -termName rxvt -e /usr/bin/bash --login -i Do you know a good tutorial to configure mintty or can you help me! Thank's, Philippe. Hello Philippe. If you run mintty and click on the icon in the upper left, you will see that an 'Options' option is available. Most of what you want can be set up in there and it will be saved to your .minttyrc file automatically. -Jason -- 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: configure rxvt on cygwin 1.7.5
On 7/8/2010 4:22 PM, philippe wrote: Jeremy Bopp a écrit : [...] However, if rxvt used to work for you under Cygwin 1.5, you might be able to make it happy again by changing your LANG setting to LANG=C. No, i don't know where to modify this option LANG :-) LANG is an environment variable. Under Cygwin 1.5, LANG=C was the default, but under Cygwin 1.7, LANG=C.UTF-8 is the default. This change is probably why rxvt stopped working for you out of the box. I highly recommend mintty. ok, mintty is distributed with cygwin and seems to be a nice terminal. I've search a little about mintty configuration, i understand that i've to move ~/.profile to ~/.minttyrc, but it's not sufficient to traduce in ~/.profile is something entirely different than ~/.minttyrc. They have completely different functions. The former sets up your shell environment while the latter configures mintty (the terminal) itself. There is nothing at all to move from one file to the other. a mintty syntax my ~/.Xdefault or the command below : rxvt -fn -*-Courier-medium-r-*-18-*-*-*-*-iso8859-1 -geometry 90x30 -sr -bg #d5 -fg black -sl 8000 -termName rxvt -e /usr/bin/bash --login -i Do you know a good tutorial to configure mintty or can you help me! As Jason already informed you, mintty has an options dialog you can use to configure it. The equivalents of your rxvt options, except for the -e option, can be configured there and saved automatically to ~/.minttyrc so that future runs of mintty automatically have the right settings without the need for a long, complicated set of command line options. However, most if not all of the options can be set via the command line as well if that's your preference. See man mintty for details. For your -e option, simply run mintty with a single - as the only option, i.e. mintty -. That will tell mintty to run an interactive login shell for your user as specified in /etc/passwd. As you'll see in the manpage for mintty, mintty does have a -e option, but there really isn't any need to be so verbose about the shell to start for most people. Set the shell program you want to use in /etc/passwd, and let mintty do the rest. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: configure rxvt on cygwin 1.7.5
On Fri, 09 Jul 2010 00:41:25 +0200, Jeremy Bopp jer...@bopp.net wrote: On 7/8/2010 4:22 PM, philippe wrote: Jeremy Bopp a écrit : [...] However, if rxvt used to work for you under Cygwin 1.5, you might be able to make it happy again by changing your LANG setting to LANG=C. No, i don't know where to modify this option LANG :-) LANG is an environment variable. Under Cygwin 1.5, LANG=C was the default, but under Cygwin 1.7, LANG=C.UTF-8 is the default. This change is probably why rxvt stopped working for you out of the box. If you want to continue with rxvt and want to keep it as close as possible to the old behavior set export LANG=C.ISO-8859-1 export LC_TIME=C in .profile Works for me. The LC_TIME is to keep ls -l produce the standard time strings. Michael -- 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
Interesting discovery in the C library that Cygwin uses
Hello! I made this discovery whilst building the urjtag program from its SVN trunk: make[3]: Entering directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' CC tap.lo CC register.lo CC state.lo CC chain.lo CC detect.lo detect.c: In function `find_record': detect.c:89: warning: array subscript has type `char' detect.c:96: warning: array subscript has type `char' detect.c:107: warning: array subscript has type `char' detect.c:125: warning: array subscript has type `char' detect.c:134: warning: array subscript has type `char' detect.c:150: warning: array subscript has type `char' make[3]: *** [detect.lo] Error 1 make[3]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag' make: *** [all] Error 2 -- The fix, temporarily as it happens was to add to the configure script this one: --disable-werror . The chap who suggested it also suggested that I complain here. It was described as an isspace() has an issue, I won't use the term he used. The code can be found at http://urjtag.sf.net as it happens. Basically the program supporter there wants the people here for Cygwin to, ah, fix their C library. I'm not convinced that's necessary, but which C library is used here? And what could be fixed? - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. -- 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: cygport patch: suppress libtool fixup step
On 08/07/2010 21:52, Charles Wilson wrote: 3) Now, if we want to have a *single* consolidated location for the $target DLLs -- so that you can actually RUN the stuff you build, Ah, that's your mistake, right there. It is only an accident that the binaries we compile with this particular cross-compiler happen to be executable on the same box that the cross-compiler runs on, but that doesn't make it not cross-compilation (it's the same host, but not the same $host), and I don't think we should do special anything just in order to make them immediately or easily executable. We offer an i686-pc-cygwin environment in which there is a cross-compiler to (one or more of) *-pc-mingw*; but that's a different host, and if someone wants to then *run* the cross-targeted binaries they've just compiled, they need to *install* them into a mingw installation (which also may happen to be on the same physical machine, but could just as well be on another). There's no reason to try and arrange things that any of the generated DLLs end up somewhere we can execute them from, I think that's a category error. Well, yes...I agree with Doug Semler that by default, the -bindir argument should be $(toolexeclibdir) and not $(bindir) for cross builds. Yes, he's right, that's definitely the way to go. And so any cross-compiler we offer on cygwin should probably also leave the binaries there in the gcc private dir, just as a convenience for those who want to *package* - not in order to make anything directly *executable*. I'm just arguing that for the *specific* case where $host=cygwin and $target=mingw* (e.g. we know that the underlying platform ALSO supports running the target executables and DLLs), I see where you're coming from, but I'm not sure how much it really buys us; and if we simply write that off - just declare that all mingw flavours are cross-hosts and you need to package and install stuff that you've cross-compiled before it will necessarily work (and of course, 32-bit mingw folks tend to prefer to have everything statically linked in monolithic executables exactly to avoid having to distribute dlls with their apps) - I think we can just skate round the issue and say that you can't necessarily run a cross-compiled *-pc-*mingw* app straight out of its build dir any more than you could a cross-compiled *-*linux* or a mips*-*-* app. I don't suppose that the mingw cross-compilers in standard linux distros try to install their runtimes into /usr/bin just because you might maybe have wine available, do they? 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: 1.7.5: Error when invoking ghostscript (gs)
Falk Sticken sticken at informatik.uni-luebeck.de writes: Hi, when I try to invoke gs from the Cygwin shell prompt, I get following error message: /usr/bin/gs.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory Falk: Sounds like U're missing a DLL. Use cygcheck without any switches to get a list of all the DLLs, then look for *all* of them in the list U attached to your last message. -tanstaafl -- 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: Interesting discovery in the C library that Cygwin uses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gregg Levine wrote, On 9.7.2010 1:34: Hello! I made this discovery whilst building the urjtag program from its SVN trunk: make[3]: Entering directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' CC tap.lo CC register.lo CC state.lo CC chain.lo CC detect.lo detect.c: In function `find_record': detect.c:89: warning: array subscript has type `char' detect.c:96: warning: array subscript has type `char' detect.c:107: warning: array subscript has type `char' detect.c:125: warning: array subscript has type `char' detect.c:134: warning: array subscript has type `char' detect.c:150: warning: array subscript has type `char' make[3]: *** [detect.lo] Error 1 make[3]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag' make: *** [all] Error 2 The fix, temporarily as it happens was to add to the configure script this one: --disable-werror . The chap who suggested it also suggested that I complain here. It was described as an isspace() has an issue, I won't use the term he used. The code can be found at http://urjtag.sf.net as it happens. Basically the program supporter there wants the people here for Cygwin to, ah, fix their C library. I'm not convinced that's necessary, but which C library is used here? And what could be fixed? - From the ctype.h: /* These macros are intentionally written in a manner that will trigger a gcc -Wall warning if the user mistakenly passes a 'char' instead of an int containing an 'unsigned char'. Note that the sizeof will always be 1, which is what we want for mapping EOF to __ctype_ptr__[0]; the use of a raw index inside the sizeof triggers the gcc warning if __c was of type char, and sizeof masks side effects of the extra __c. Meanwhile, the real index to __ctype_ptr__+1 must be cast to int, since isalpha(0x10001LL) must equal isalpha(1), rather than being an out-of-bounds reference on a 64-bit machine. */ #define __ctype_lookup(__c) ((__ctype_ptr__+sizeof([__c]))[(int)(__c)]) The interesting part: These macros are intentionally written in a manner that will trigger a gcc -Wall warning if the user mistakenly passes a 'char' instead of an int containing an 'unsigned char'. And this is from SUSv3: The c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. His code invokes undefined behaviour in case the char value is negative. The warning is a good thing. He IMHO needs to fix his code. - -- VH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMNqTjr2CghdezFMkRCOKcAKDAjf97aQkCOMnChHklmF1h0P777gCfSfCo 7iVQdH4YBv9uPhyW0xNfAZo= =smu3 -END PGP SIGNATURE- -- 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: Interesting discovery in the C library that Cygwin uses
On 2010-07-08 23:34Z, Gregg Levine wrote: I made this discovery whilst building the urjtag program from its SVN trunk: make[3]: Entering directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap' CC tap.lo CC register.lo CC state.lo CC chain.lo CC detect.lo detect.c: In function `find_record': detect.c:89: warning: array subscript has type `char' http://urjtag.svn.sourceforge.net/viewvc/urjtag/trunk/urjtag/src/tap/detect.c?annotate=1799 char *p; ... while (*p isspace (*p)) The problem is that 'char' can be signed, and a signed quantity can be negative. But values passed to ctype.h functions like isspace() have to be in the (nonnegative) range of an unsigned char (or be equal to EOF); otherwise, the behavior is undefined. Consider using unsigned char *p; instead of char *p; in the example above. Here's some discussion: https://www.securecoding.cert.org/confluence/display/seccode/STR37-C.+Arguments+to+character+handling+functions+must+be+representable+as+an+unsigned+char http://old.nabble.com/warnings-from-use-of-ctype.h-methods-td27865685.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: configure rxvt on cygwin 1.7.5
On 9 July 2010 00:01 lemkemch wrote: If you want to continue with rxvt and want to keep it as close as possible to the old behavior set export LANG=C.ISO-8859-1 export LC_TIME=C in .profile Setting LANG in .profile is too late for bash itself, because that will continue to operate in C.UTF-8. That will cause trouble when entering non-ASCII characters on the command line, for example, try typing an ä or â. Therefore you need to set it before bash is invoked, for example in cygwin.bat if that's where you're invoking rxvt from. 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: configure rxvt on cygwin 1.7.5
On 8 July 2010 23:41, Jeremy Bopp wrote: As Jason already informed you, mintty has an options dialog you can use to configure it. The equivalents of your rxvt options, except for the -e option, can be configured there and saved automatically to ~/.minttyrc so that future runs of mintty automatically have the right settings without the need for a long, complicated set of command line options. However, most if not all of the options can be set via the command line as well if that's your preference. See man mintty for details. For your -e option, simply run mintty with a single - as the only option, i.e. mintty -. That will tell mintty to run an interactive login shell for your user as specified in /etc/passwd. As you'll see in the manpage for mintty, mintty does have a -e option, but there really isn't any need to be so verbose about the shell to start for most people. Set the shell program you want to use in /etc/passwd, and let mintty do the rest. Good advice. Also, it's easiest just to invoke mintty from the start menu shortcut in the Cygwin folder that's created when mintty is installed. That already has that '-' argument. 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
