Re: GCC-4.7.2-2: Go/No-go?
On 17/04/2013 19:59, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:32, Dave Korn wrote: On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote: Your boehm-gc patch can replace my java-libgc-win32.patch, provided it works properly. It appears to, libjava testsuite results are as good as they've ever been, although I don't know whether or not the testsuite checks the invocation API. It's certainly the more complete approach to take than just not supporting the register/unregister methods, as confirmed by the fact that upstream boehm-gc has implemented it for Cygwin. There is a mistake in that patch. The DEBUG_CYGWIN_THREADS conditionals need to be if, not ifdef, as elsewhere in the same source file. Oops, that was a cut'n'paste error when I copied the skeleton of those functions from pthread_support.c, where #ifdef DEBUG_THREADS is the form to use. Thanks for spotting it; fixed in my repo ready for next release. cheers, DaveK
Re: [ANNOUNCEMENT] Updated: expat 2.1.0-1
On 16/04/2013 14:25, Warren Young wrote: On 4/11/2013 14:38, Dave Korn wrote: The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is missing in 2.1.0-1(**), was that intentional? I think I got that, um, feature for free when I converted to cygport for that package. Someone is passing --disable-static to the configure script, and it isn't me. I've fixed this with CYGCONF_ARGS=--enable-static The static library does now appear in the -devel package. The .a is about 3x the size of the .dll. Is that normal, or am I supposed to be stripping the .a before packaging it? Yes, totally normal, it's a whole set of individual object files with all their overhead, rather than just the linked text/data content of those files. No, don't strip it, that decision should be left until linking a final executable. Does someone actually want this static library? I'm going to RFU it anyway, since I've gone to the trouble of fixing it, but I was curious if it actually mattered to someone. GDB apparently prefers linking statically to libexpat. Dunno why, but it saves me adjusting my dependencies in a package I'm shipping to a customer, so thanks :) 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: Debugging totally broken with latest everything?
On 15/04/2013 18:14, Christopher Faylor wrote: On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote: Some notes on the above: The same happens with both the previous version and current snapshot of the cygwin dll. It also happens with both current gdb and an old gdb 6.8.0.20080328-cvs that I have lying around. The hw.exe in question is your bog-standard hello world, compiled with -g -O0 using gcc4-4.5.3-3. kill -9 won't kill gdb; I have to use Windows task manager. If I've attached gdb to the hung gdb, I can kill it from there using the k instruction. Anyone else having similar problems? You're probably seeing a known bug in gdb where it no longer works well when run from a console window. There is a race where gdb tries to get tty information from a stopped cygwin process. Although I didn't introduce the problem, I have tried to fix it from time to time without much luck. It must be an interaction between gdb and the cygwin dll, since my old-and-previously-working-just-fine-in-a-console gdb-6 has also stopped working. Debugging from mintty will probably work better. It certainly does. Thanks for the tip. 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: 64bit: cygstdc++-6.dll
On 13/04/2013 11:07, Corinna Vinschen wrote: On Apr 12 21:31, Dave Korn wrote: Nope, just vague about input and output sections. Enabling auto imports selects a linker script that causes all the .rdata in the input object files Out of curiosity, which linker script is that? What's the difference to the normal one? Well, since auto import became the default, it is the normal one, but that aside, they're both built-in scripts. Compare the output from ld --disable-auto-import --verbose and ld --verbose to see the difference. Or you can look at the copies that ld installs into /usr/i686-pc-cygwin/lib/ldscripts/; the .x file is the plain one, the .xa is the auto-import one. to be placed in the plain old .data section of the output executable, so that it will be RW-mapped when loaded. Apparently the Windows runtime loader can't deal with updating import references into RO-mapped pages. The consequence of that is that all the pages with import references get modified and COWed on load and so it reduces the amount of the mapped memory that can be shared between instances of the same executable. I'm a bit puzzled in terms of the additional R/W space this amounts to. When loading an executable, there is the entire IAT which has to be modified by the loader, anyway. That includes all functions and data imported from other DLLs. To what extent do the auto-import entries add to that? If it's just another indirection, that would add 5 bytes (absolute jmp) on i686, and 8 bytes (an absolute address in a pseudo-GOT table) on x86_64 per auto-imported symbol. That's not a lot, probably not even a 4K page per executable. How significant is that? But it's not a separate contiguous list of pointers. What's happening is that there are various structures in the .rdata that contain imported pointers. They'll be scattered throughout the .rdata, along with all the other const data that /doesn't/ have pointers that have to be auto-imported. So depending on the percentages and how it happens to end up in the link order, it could be any or all of the .rdata pages that get COWed on startup. I'm not sure how significant this is in general usage, and I'm generally in agreement that removing auto-import would be a significant hassle. That, too. Yeah. So I guess we have to live with it. However it's probably still worth having the markers in libstdc headers, because that at least makes it possible for people to write applications and disable auto imports if they're only using libstdc (and/or other shared libs that also have markers in their headers). That would be desirable for something that you're going to want to spawn many instances of (either consecutively or concurrently). cheers, DaveK
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 13/04/2013 15:49, Corinna Vinschen wrote: On Apr 13 12:39, Andy Koppe wrote: On 13 April 2013 10:03, Corinna Vinschen wrote: On Apr 13 06:55, Andy Koppe wrote: I'm struggling to get setup.hint generation to work. Is it supported with cygport 0.11.3 as currently in the distros? Below is the mintty.cygport I've got. Do I need to do anything else to trigger it? Cygport prints mintty requires: at the end, which is correct as it doesn't require anything beyond the Cygwin DLL, but there's no setup.hint. Sure? Did you look into the dist subdir in your builddir after the install stage? It should contain a complete mintty dir for upload. You're right, there is, inside the working directory created by cygport, and it looks correct. I'd expected the setup.hint to appear next to the .cygport and the packaged .tar.bz2 files. IIU Yaakov C, the dist dir is the way to go in future. The toplevel files is the old style, supposed to go away at one point. I like the dist dir approach a lot. Glad to hear that. I also much prefer the dist dir to plonking all the files in the toplevel with no directory structure. It's much simpler for uploading. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 21:42, Thomas Wolff wrote: Am 11.04.2013 14:34, schrieb Dave Korn: Also, I don't plan on doing it unless there's significant demand. I would appreciate to keep it as gcc-3. Fancy being the maintainer for it then? ;-) The reason is quite peculiar; gcc-4 changed the order of variables in the stack frame of a function call, which led to one very specific interworking malfunction (between mintty and mined) which in turn unveiled a very subtle bug. This is material for very interesting debugging exercises for students... Not sure whether it's significant but the changed variable order might in fact affect other software as well. -- Thomas Only seriously buggy software. Anything in a C program that attempts to make inferences about the layout of the stack frame is invoking undefined behaviour. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 12/04/2013 11:44, Yaakov (Cygwin/X) wrote: On 2013-04-11 23:24, Dave Korn wrote: Most of the discussed features are already in the latest release. Right now, the major difference between the release and git master is full support for x86_64-pc-cygwin, but there are a number of other bugfixes and enhancements. I hope to cut a release from master as early as next week. (Also, what is the unversioned file format?) Where the file is named foo.cygport and NAME/VERSION/RELEASE are defined inside of the cygport(5) instead of deriving these from the filename as before. My gcc.cygport is an example of this, as well as the use of setup.hint generation. Great, then I'll take full advantage of the new stuff. Huh? Cygport doesn't own CC any more than autotools if it's not being used. CC is a user variable. It belongs to make, and the make info page in the section on Makefile Conventions says that the user can substitute alternatives. Maintainers aren't the only people who use the compiler! *Within the scope of cygport*, cygport(1) is the user and it controls CC based on a number of factors. [ ... ] Saying CC=gcc-4 obviously doesn't work in all those scenarios. Well, yes, but we're talking here about whether I should leave a symlink called gcc-4.exe in /usr/bin for the benefit of any end users who might have makefiles (or other scripts) that aren't in any way related to cygport at all, so none of that is relevant. You still haven't explained exactly what the problem is. You don't need libgcj on the system in order to build a native gcc with java. Why would the presence or lack of libgcj*.la make a difference? Ah, that's where our misunderstanding is. It's the presence of libstdc++.la that is required for libjava to build, not libgcj.la. [ ... ] Oh, now I get it. What *really* happened is that last time you tried this, you still had GNOME .la files on your system, some of which contained references to libstdc++.la because of the then-embedded copy of harfbuzz in the Pango libraries. So when you installed an .la-less gcc then rebuilt gcc, the link failed because of the remaining libstdc++.la references in libgtkpeer's many (sub)deps; the same would have happened building *any* GTK+/GNOME package with libtool. This would have worked even then if you had run the fix-libtool-scripts-for-latest-gcc-runtimes.sh script with my modifications thereto (Ports gcc commit 00c6f36) immediately after installing the .la-less gcc. In any case, the current versions of the GNOME libraries do not include .la files, so you won't have this problem with rebuilding gcc. (You should still run the modified script in any case.) Ah, thanks for the explanation. That makes sense to me. Don't get me wrong, libtool is still the best option for building libraries portably, but it does not need .la files on the system to do so with shared libraries. Now that we've figured out what the problem really was, and that it doesn't exist anymore, could we drop them from the next release? Absolutely, assuming nothing goes wrong when I test it. I should still package the updated version of fix-libtool-scripts-for-latest-gcc-runtimes.sh and invoke it postinstall for the benefit of any other .la files that are still on the system, right? cheers, DaveK
Re: 64bit: cygstdc++-6.dll
On 12/04/2013 16:57, Corinna Vinschen wrote: Dave? Ping? Heh, don't panic, I'm still here! Just needed some sleep :) On Apr 11 15:37, Corinna Vinschen wrote: On Apr 11 12:16, Corinna Vinschen wrote: On Apr 10 18:16, Corinna Vinschen wrote: On Apr 10 16:49, Dave Korn wrote: On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote: Could you explain the necessity of the dllimport's in the same patch? The idea is to one day be able to move away from having auto-import enabled by default in binutils, so that .rdata can go back into the read-only-mapped .rdata section and be shared between processes as it ought. Doesn't that affect applications which use something like extern int optind; in their code? Kai did quite a job to get this working on x86_64 by implementing the medium/large code models for x86_64, and Cygwin's x86_64 gcc uses the medium code model by default. Disabling this again would be rather counterproductive. What about this issue? If the idea is to revert all automatism which allows to declare external variables in DLL s without dllimport, then I don't think that's a good idea for Cygwin. If I misunderstand the issue, please say so. Oh, and, btw., I don't quite understand so that .rdata can go back into the read-only-mapped .rdata section Typo? Nope, just vague about input and output sections. Enabling auto imports selects a linker script that causes all the .rdata in the input object files to be placed in the plain old .data section of the output executable, so that it will be RW-mapped when loaded. Apparently the Windows runtime loader can't deal with updating import references into RO-mapped pages. The consequence of that is that all the pages with import references get modified and COWed on load and so it reduces the amount of the mapped memory that can be shared between instances of the same executable. I'm not sure how significant this is in general usage, and I'm generally in agreement that removing auto-import would be a significant hassle. I think it might explain why, when I'm running the GCC testsuite and have been through a few tens of thousands of compiles, I frequently see a whole bunch of gcc.exe instances just sitting there, doing nothing and using almost no CPU for 20 to 30 seconds while their stack traces indicate they're stuck in kernel paging-and-caching-related code. But overall, I guess we have to live with it. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote: On 2013-04-10 11:56, Dave Korn wrote: It takes 11 hours on a triple-core machine at -j6 to build and package GCC. In order to guarantee consistent reproduction I always respin the built package from -src package through two generations. It then takes three to five days to run enough of the testsuite to be confident that the packaged compiler works well. So it'd be next week at the earliest. While your diligence is admirable, I think some common sense review can be used here, as only one of my patches actually affects the compiler itself, and even then only the specs. I'm not exactly messing around with code generation here. Yes, I've looked at most of your patches already, I'm not saying there's any complication in adding them, it's just that I didn't want to wait another howevermany days before getting 4.7.2-2 out there. I'll put them all into the next release, which I'll get on with pronto. BTW, in your absence, it was agreed that gcc3 should go away and that gcc4 should be *the* gcc in the distro. This will simplify the build and drop the dep on 'alternatives'. Can this get into the next release? Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was using it and wants to know where it's gone. (I suppose if that happens I could always consider rolling a gcc3 package with all -3 suffixed executables.) I'll need to make sure not to lose the cc.exe - gcc.exe symlink, and it might be useful for backward-compatibility to provide a bunch of -4 suffixed links to the other executables for people who've written CC=gcc-4 in their Makefiles, but that can be done with just ln rather than using alternatives. I don't understand why there's a libquadmath0-devel; like the other C libraries, this should just be part of gcc-core. Hmm. I got the impression that libquadmath could stand alone, i.e. be useful in a non-GCC context, but I guess not or it would be installing its include files into /usr/include rather than the GCC private include dir. I'll merge it into gcc-core in the next release as you suggest. This was only necessary for libstdc++, and only so long as .la files were included. IIRC we agreed to remove them, but your reason for not doing so in the .cygport isn't clear to me. Without the .la files, libjava doesn't build. And in general I don't want to second-guess the compiler: since the upstream makefiles think it's important to install them, so do I. Also, could you please explain the reasons for the ehdebug, execstack, and shared-libgcc patches? ehdebug: When we first switched from sjlj to dw2 exceptions, there were so many corner case bugs that kept cropping up across multiple releases that I wanted to hang onto the debugging code. During development the debugging output was under control of a variable that I replaced by a #define 0 just before the release. It's obsolete now, I'll drop it, but it was incredibly useful for the first few gcc4 releases. execstack: Trampolines need an executable stack. DEP on recent Windows OSs marks the stack non-executable; this option allows the stack to be set executable during the runtime startup, without having to disable DEP for the entire process. Think I may have inherited it from Danny Smith. Mingw has it upstream, I'll get it committed there for Cygwin too. shared-libgcc: Makes linking against shared libgcc the default for all executables; previously it was only on by default for DLLs. Vital for importing TLS variables from DLLs, upstream since 4.8.0. cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 05:47, Christopher Faylor wrote: On Thu, Apr 11, 2013 at 02:21:00AM +0100, Dave Korn wrote: On 11/04/2013 02:05, Dave Korn wrote: On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. Should be ok now I trust. Apologies once more, I've updated my local hint file in svn to prevent it happening again. No problem. Your fix is confirmed. Thanks for the quick response. cgf Being a confirmed cynic^W^Wexperienced programmer, I always like to stay online for a while after committing or releasing something, in case of any aftermath. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 11/04/2013 03:44, Yaakov (Cygwin/X) wrote: On 2013-04-10 20:40, Dave Korn wrote: Surely there'll be a problem if the curr: version of everything else goes to 4.7.3-1 but there's no matching version of libffi4? Not as long as 4.5.3-3-src remains. Well, there have been some bugfixes in gcc/libffi upstream, so as long as anyone out there might conceivably have some homebrew app that they've linked against libffi4, I'd like to do them the favour of giving them a final updated version to live with until they get round to rebuilding against libffi6. It's no skin off my (or anyone else's) nose as far as I can see. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 11:13, Corinna Vinschen wrote: On Apr 11 01:58, Yaakov (Cygwin/X) wrote: On 2013-04-11 01:02, Dave Korn wrote: Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was using it and wants to know where it's gone. (I suppose if that happens I could always consider rolling a gcc3 package with all -3 suffixed executables.) 3.4 is EOL and should have been dropped long ago; we simply don't have the resources to support it ourselves. Just about any software that people are building today either works with recent 4.x or the distros have a patch for it. FWIW, I agree. AOL-Corinna I said I could consider it, I didn't say I was necessarily going to do it :) Still, you'd be surprised the number of questions I see on random websites (stackoverflow, linuxquestions and similar) where someone's asking how to install an old GCC to build some old software. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 11/04/2013 13:22, NightStrike wrote: Speaking of which.. 4.8 is out... Point. Anyone got any particular preference whether I go for a 4.7.3 or 4.8.0 release next? Maybe do a 4.7.3 curr: and then a 4.8.0 test: package? cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 12/04/2013 00:36, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:35, Dave Korn wrote: On 11/04/2013 13:22, NightStrike wrote: Speaking of which.. 4.8 is out... So is GNOME 3.8.0, but I tend to let others deal with the early bugs and catch up by .1 or even .2. Point. Anyone got any particular preference whether I go for a 4.7.3 or 4.8.0 release next? Maybe do a 4.7.3 curr: and then a 4.8.0 test: package? For the same reason, I'd go with 4.7.3 first. But let's not wait until 4.9 to update GCC again this time, okay? :-) Yeh, promise! cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:32, Dave Korn wrote: On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote: Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies to 4.7 as well. I'll take a look for that. Does it really matter? I don't suppose we need support swapping LTO plugins between different versions of the compiler, it's totally a for-internal-use-only thing. Does it really, *really* matter? Perhaps not, but IMO it's the proper thing to do for all arches, since the LTO plugin is just that, a plugin. (If Apple were to still use GCC, it *would* matter, as there are fundamental differences between Mach-O dylibs and bundles.) Well, maybe I'll just wait until I get to a 4.8 release naturally and let it happen then. Or maybe I'll backport the patch for 4.7.3. I'll see how I feel at the time, since it's not /critical/ and I'd like to prioritise. Something else you missed: cygport supports a new, unversioned file format, and creates setup.hint files, including dependency detection. I suggest using git master right now. Wouldn't that mean that the -src package I ship won't rebuild with the version from the standard distribution? I usually recommend using cygport git master, and a number of maintainers track it. I want to ship packages that the general public can rebuild using the standard distro really. Do you have any idea of a schedule for releasing these features? (Also, what is the unversioned file format?) That was never right, CC isn't supposed to be (ab)used like that. I don't mind not supporting that going forward. Well it's not exactly any trouble so I may as well do it. If you're not using autotools, CC is yours to do what you like with isn't it? No, it's not. In the cygport manual, [Definitions] should be treated as readonly, and [Variables] can be altered. Huh? Cygport doesn't own CC any more than autotools if it's not being used. CC is a user variable. It belongs to make, and the make info page in the section on Makefile Conventions says that the user can substitute alternatives. Maintainers aren't the only people who use the compiler! How could removing the .la files during postinstall affect building libjava beforehand? Heh, of course not, I'm not suggesting time travel! I should have said *re*build: without the .la files installed on the user's system, the -src package fails to rebuild. I imagine (but didn't test) that applies to building plain upstream SVN/tarball as well. You still haven't explained exactly what the problem is. You don't need libgcj on the system in order to build a native gcc with java. Why would the presence or lack of libgcj*.la make a difference? Ah, that's where our misunderstanding is. It's the presence of libstdc++.la that is required for libjava to build, not libgcj.la. That's because of a failure during linking (the awt peer IIRC) when libtool can't locate libstdc to link against. That in turn happens because it uses gcc.exe to link, not g++.exe, and that in turn happens because libtool is invoked with the CC tag, not CXX, and that in turn happens because the module is composed entirely of .c files and does not have any .cc files to trigger libtool's language detection to know that C++ is required. As for the makefiles installing the .la files, upstream isn't choosing to do so, that's just how libtool works. Some Linux distros, including Fedora, have been removing them from all binary packages (except when they are needed by lt_dlopen() and friends), and for very good reason. What's the very good reason? Because they cause more trouble than they're worth, e.g. necessitating hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh. This is a good summary of some of the issues: https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html Hmm. I need to digest that some more. I'm not entirely certain that it applies to the compiler runtime libs, because people often do use static linking against them when they want to make standalone executables. shared-libgcc: Makes linking against shared libgcc the default for all executables; previously it was only on by default for DLLs. Vital for importing TLS variables from DLLs, upstream since 4.8.0. Here we go again... Huh? We started with 4.3 using the static libgcc by default, then switched to linking everything with -lgcc_s, then with 4.5 switched to doing so by default only for DLLs (to minimize rebase errors iirc), and now we're going back to shared across-the-board. I'm not complaining, and it seems like the right thing to do, but it does evoke a sense of deja vu. Ah, I didn't remember that we'd taken a step back at one point during the process, I thought it had been a linear progression but that does ring a bell. Well, I'm sure now that it was the wrong way to try and solve the rebase problems, it's seriously
Re: FIXED: GCC can't find its header directoriescy
On 11/04/2013 07:08, Duncan Roe wrote: Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. Glad to hear it! I put them there because I like to have the odd cygwin utility available to CMD.EXE. May put them back - but will take more care with them in future, The better way to do that is just to add your cygwin\bin dir to your PATH in the Windows environment variables. That way you get all your cygwin stuff available in cmd.exe but it's always the up-to-date stuff from your main installation. (The only problem I've ever run into in this approach is that both Cygwin and MSVC have a link.exe command, so you can end up getting the wrong one. You can avoid this by any combination of specifying full paths to the particular one you want, choosing whether to put cygwin\bin at the start or end of your Windows PATH, or customising your vcvars.bat to make sure the MSVC version is earlier in the PATH when you launch it. I've never found it to be a big problem compared to the convenience of having a real grep available in cmd.exe!) 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: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.7.2-2
On 11/04/2013 00:58, Dave Korn wrote: I would like to express my gratitude to JonY for stepping into the breach caused by my absence from the Cygwin community and releasing the first test version of GCC 4.7 series. He did a very difficult job and did it well and deserves the highest of praise for doing so. It was suggested to me off-list, and I concur, that this is worthy of a gold star, if not two. May it please the maintainer of the stars to consider my request? 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: [ANNOUNCEMENT] Updated: expat 2.1.0-1
On 12/06/2012 13:31, Warren Young wrote: PACKAGE DESCRIPTION === Homepage: http://sourceforge.net/projects/expat/ License : MIT-like Expat is a C library for parsing XML, originally created and maintained by James Clark, but since 2001 taken over by a loose group of contributors. CYGWIN-SPECIFIC CHANGES SINCE LAST RELEASE == None. This release simply tracks the 2.0.1 - 2.1.0 upstream release. The static archive /usr/lib/libexpat.a was present in 2.0.1-1(*) and is missing in 2.1.0-1(**), was that intentional? cheers, DaveK -- * - http://cygwin.com/packages/libexpat1-devel/libexpat1-devel-2.0.1-1 ** - http://cygwin.com/packages/libexpat1-devel/libexpat1-devel-2.1.0-1 -- 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: 64bit: cygstdc++-6.dll
On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote: Could you explain the necessity of the dllimport's in the same patch? The idea is to one day be able to move away from having auto-import enabled by default in binutils, so that .rdata can go back into the read-only-mapped .rdata section and be shared between processes as it ought. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On 10/04/2013 16:47, Christopher Faylor wrote: It isn't clear to me why we'd be spending days discussing this when presumably the patches apply without too much effort. Some of the patches here: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc look worthwhile to me. If we're talking about only gcc 4.7 fixes then it looks like we're only talking about five patches, none of them are to source files, and none of them are very big. It takes 11 hours on a triple-core machine at -j6 to build and package GCC. In order to guarantee consistent reproduction I always respin the built package from -src package through two generations. It then takes three to five days to run enough of the testsuite to be confident that the packaged compiler works well. So it'd be next week at the earliest. Hence I'm uploading 4.7.2-2 now. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote: On 2013-04-10 04:29, Corinna Vinschen wrote: On Apr 10 04:06, Yaakov (Cygwin/X) wrote: libffi development moved out of GCC into a separate project a long time ago; the copy included in GCC is used for libgcj, but only as a convenience (static) library, and it is usually a few point releases behind the standalone version. Finally, last month, GCC was patched upstream to stop installing its copy (a similar patch for 4.7.2 and 4.8.0 is in Ports git). Therefore I think the time has arrived to join Fedora and Debian and switch i686 to the standalone version. (We are already using this for x86_64.) This will also simplify building many of the ~20 packages which use libffi and expect the .pc file provided only by the standalone version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/ Isn't that independent from what gcc itself does? If so, feel free to upload. Only the man3 pages collide with gcc4-core. But gcc's libffi.dll.a will take priority over the one in /usr/lib (see gcc -print-search-dirs), so manual intervention will be necessary until our gcc stops shipping libffi. Okeydokey. Upstream libffi generates cygffi-6.dll, so what I'll do is incorporate the patch (along with your others) into 4.7.3-1 (which will be a full curr: version release), and ship one last version of libffi4 (marked obsolete) with that but make sure the man pages, static import lib etc (-devel stuff basically) is not packaged. That'll probably be in ten days or so, at which point you can upload the standalone libffi. Makes sense? cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 02:05, Dave Korn wrote: On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. Should be ok now I trust. Apologies once more, I've updated my local hint file in svn to prevent it happening again. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 11/04/2013 02:33, Yaakov (Cygwin/X) wrote: After applying my libffi-noinst.patch, all you really need to do is remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro until all libffi-dependent packages are rebuilt (most of which are mine). Surely there'll be a problem if the curr: version of everything else goes to 4.7.3-1 but there's no matching version of libffi4? cheers, DaveK
[ANNOUNCEMENT] Updated: experimental package: gcc4-4.7.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This is a test release of GCC 4.7.2 which replaces the earlier test release. It reverts the package dependencies in the Cygwin repository to those that are correct for the current full version of GCC, 4.5.3-3, as setup.exe can only support one set of dependencies for all versions of a package. This means you may need to select some of the new packages manually, depending on the set of languages you are installing; see the important note section in From the README below. In addition, this release restores libffi and java which were unavailable from the previous test version. It also makes linking against shared libgcc the default for executables as well as DLLs, which is necessary for correct sharing of thread-local variables imported by executables from DLLs. I would like to express my gratitude to JonY for stepping into the breach caused by my absence from the Cygwin community and releasing the first test version of GCC 4.7 series. He did a very difficult job and did it well and deserves the highest of praise for doing so. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a test version release, you will need to manually select any packages and dependent libraries you require: see below for full details. NEWS From the README: IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES === Cygwin's setup.exe does not handle a situation where an experimental package version has different dependencies from the main current version. For this reason, the dependencies listed in the Cygwin package repository are those required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be correct for the majority of users. Anyone wishing to install the test version of GCC will need to ensure they select manually select the corresponding new versions of the runtime libraries required. These dependencies are: gcc4-java: Requires libgcj13. gcc4-objc: Requires libobjc4. gcc4-ada: Requires libgnat4.7. gcc4-fortran: Requires libquadmath0, libquadmath0-devel. libgfortran3: Requires libquadmath0. Cygwin port maintained by: Dave Korn dave.korn.cygwin AT gmail.com.use.the.list.please Please address all questions to the main Cygwin mailing list. This is the key used for signing Cygwin GCC releases: pub 1024D/6A388C3E 2008-05-31 uid Dave Korn (release signing key) dave.korn.cygwin AT gmail.com sub 4096g/D4E41590 2008-05-31 Also available at a key-server near you! - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (Cygwin) mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR 8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8 d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9 ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO 10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5 CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52 +MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S 0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP 2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi 5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh
Re: 1.7.15: gcc fails to load: missing cygmpfr-4.dll
On 11/04/2013 02:57, Duncan Roe wrote: I have just installed cygwin on this system. When I try to compile a small program, I get this error: /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory Sorry about that, I missed a dependency when I uploaded it. It's actually fixed as of a few hours ago, but the fix must not have reached your mirror yet. Just use setup.exe to install libmpfr4. 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: GCC can't find its header directoriescy
On 11/04/2013 06:12, Duncan Roe wrote: Thanks guys for the pointers to cygmpfr-4.dll. Got it. This problem with headers started happening on an old installation so I reinstalled but it still happens: ignoring nonexistent directory /usr/include strerror.c:2:19: error: no include path in which to search for stdio.h 12:33:27$ ls /usr/include locale.hnetdb.h reent.h stdio.h termios.h wait.h /usr/include definitely exists but gcc / cpp claims it does not. Since this just started happening I wonder whether it is caused by some update to Windows. (Win XP SP3). Anyone else seen anything like it? I'm stuck, Bizarre. I've never seen anything like it, nor your problem with altdir invalid. However I've got one guess about what might be interfering, from your cygcheck.out: 45k 2010/08/15 C:\WINDOWS\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0 cyggcc_s-1.dll v0.0 ts=2010/8/15 8:57 982k 2009/12/23 C:\WINDOWS\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0 cygiconv-2.dll v0.0 ts=2009/12/24 0:25 31k 2011/11/28 C:\WINDOWS\cygintl-1.dll - os=4.0 img=1.0 sys=4.0 cygintl-8.dll v0.0 ts=2009/4/3 12:15 31k 2009/04/03 C:\WINDOWS\cygintl-2.dll - os=4.0 img=1.0 sys=4.0 cygintl-8.dll v0.0 ts=2009/4/3 12:15 31k 2009/04/03 C:\WINDOWS\cygintl-8.dll - os=4.0 img=1.0 sys=4.0 cygintl-8.dll v0.0 ts=2009/4/3 12:15 224k 2010/06/15 C:\WINDOWS\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0 cygpcre-0.dll v0.0 ts=2010/6/15 14:10 10k 2009/12/14 C:\WINDOWS\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0 cygsigsegv-2.dll v0.0 ts=2009/12/14 23:56 2586k 2010/08/31 C:\WINDOWS\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 17:58 Cygwin DLL version info: DLL version: 1.7.7 Those could well have been interfering. Get rid of all Cygwin-related DLLs from your C:\WINDOWS folder (maybe stash them away somewhere safe in case they turn out to be needed by some Cygwin-dependent application you've got on your system), then reinstall everything using setup.exe (click on Default next to the All category in the Category view until it switches to Reinstall, ignore the couple of warning boxes that pop up on the way there) and see if it all works better once that's completed. 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
Updated: experimental package: gcc4-4.7.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This is a test release of GCC 4.7.2 which replaces the earlier test release. It reverts the package dependencies in the Cygwin repository to those that are correct for the current full version of GCC, 4.5.3-3, as setup.exe can only support one set of dependencies for all versions of a package. This means you may need to select some of the new packages manually, depending on the set of languages you are installing; see the important note section in From the README below. In addition, this release restores libffi and java which were unavailable from the previous test version. It also makes linking against shared libgcc the default for executables as well as DLLs, which is necessary for correct sharing of thread-local variables imported by executables from DLLs. I would like to express my gratitude to JonY for stepping into the breach caused by my absence from the Cygwin community and releasing the first test version of GCC 4.7 series. He did a very difficult job and did it well and deserves the highest of praise for doing so. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a test version release, you will need to manually select any packages and dependent libraries you require: see below for full details. NEWS From the README: IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES === Cygwin's setup.exe does not handle a situation where an experimental package version has different dependencies from the main current version. For this reason, the dependencies listed in the Cygwin package repository are those required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be correct for the majority of users. Anyone wishing to install the test version of GCC will need to ensure they select manually select the corresponding new versions of the runtime libraries required. These dependencies are: gcc4-java: Requires libgcj13. gcc4-objc: Requires libobjc4. gcc4-ada: Requires libgnat4.7. gcc4-fortran: Requires libquadmath0, libquadmath0-devel. libgfortran3: Requires libquadmath0. Cygwin port maintained by: Dave Korn dave.korn.cygwin AT gmail.com.use.the.list.please Please address all questions to the main Cygwin mailing list. This is the key used for signing Cygwin GCC releases: pub 1024D/6A388C3E 2008-05-31 uid Dave Korn (release signing key) dave.korn.cygwin AT gmail.com sub 4096g/D4E41590 2008-05-31 Also available at a key-server near you! - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (Cygwin) mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR 8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8 d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9 ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO 10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5 CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52 +MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S 0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP 2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi 5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh
Re: 64bit: cygstdc++-6.dll
On 25/03/2013 08:52, Corinna Vinschen wrote: On Mar 24 03:33, Yaakov (Cygwin/X) wrote: In any case, the error is a result of adding one of Dave Korn's patches: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29 I have omitted that patch in the new 4.8.0-1. Hopefully Dave can explain the purpose and necessity of that patch, since it would seem that using (at least that hunk of) it would require rebuilding most C++ packages in 64bit/release; if it's really necessary, then we will want to do that sooner rather than later. I believe the patch is no longer necessary. I added it originally after a discussion about the implications of exporting typeinfo from DLLs with Danny Smith in the GCC bugzilla; he was of opinion that there might be incomplete typeinfos that could not be fully resolved until final link-time of an application, so the purpose of this patch was to place typeinfo objects into the cygstdc++.dll.a rather than in the DLL itself. The idea being that every app that linked against the DLL would get a copy of the still-relocatable typeinfo object files from the import library during its own final link. I'm now convinced that Danny was needlessly worried. The cxx-abi does refer to this situation, in section 2.9.1: bNOTE/b: Note that the full structure described by an RTTI descriptor may include incomplete types not required by the Standard to be completed, although not in contexts where it would cause ambiguity. Therefore, any cross-references within the RTTI to types not known to be complete must be weak symbol references. But I don't think this applies to any of the built-in types in libstdc, so I think it's safe to include their typeinfo in the DLL and export it. That I don't quite understand either. If this is only about missing exported symbols and not about the name, how are the already built C++ packages affected? They could be built, so they didn't use this symbols, apparently. Removing the patch should generate a backwardly-compatible DLL. Existing applications already linked against the DLLs will have their own copies of the typeinfo objects pulled in from the import library, so it won't matter that the newer DLL also exports such a name (note that we compare typeinfos by name string under Cygwin, rather than by pointer equivalence.) New applications linking against the new DLL will simply pull in an import table reference rather than the entire typeinfo object file. The backward incompatibility came from adding the patch after previously having released a version of the DLL without the patch which therefore had all the typeinfos exported, as the applications linked against the previous version of the DLL would still expect the typeinfo imports to be available, but now the typeinfos would only be available as objects in the import library. In short: it was a precautionary measure, it's now superfluous. I'll remove it from the next full release of 32-bit GCC as well. cheers, DaveK
Re: 64bit: cygstdc++-6.dll
On 09/04/2013 11:30, Yaakov (Cygwin/X) wrote: On 2013-04-09 02:08, Dave Korn wrote: On 25/03/2013 08:52, Corinna Vinschen wrote: On Mar 24 03:33, Yaakov (Cygwin/X) wrote: In any case, the error is a result of adding one of Dave Korn's patches: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29 I have omitted that patch in the new 4.8.0-1. Hopefully Dave can explain the purpose and necessity of that patch, since it would seem that using (at least that hunk of) it would require rebuilding most C++ packages in 64bit/release; if it's really necessary, then we will want to do that sooner rather than later. I believe the patch is no longer necessary. Does that apply to the entire dllimport patch or just that hunk? Just the hunk with the --exclude-modules-for-implib. cheers, DaveK
GCC-4.7.2-2: Go/No-go?
Hi all, I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs work and restores java and libffi. I've also been running the testsuite over the last few days and the results look quite reasonable. Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that I shouldn't release it until I've integrated all his patches. I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's worth uploading as a stop-gap to address the mentioned problems and integrating Yaakov's patches for the next release. Could the list please help us make a decision? cheers, DaveK
Re: starting cygwin shell
On 07/04/2013 19:50, Christopher Faylor wrote: On Sun, Apr 07, 2013 at 06:16:17PM +, Gene wrote: save: fork_level=1 SetHandleInformation() failed: fd 0 handle 0x3 type 2: Th e parameter is incorrect. That error message doesn't seem to be coming from Cygwin. I have grepped the Cygwin DLL and *sh* and don't see it anywhere. Are you possibly using other binaries besides Cygwin ones? A quick google suggests it comes from MKS. Trying to mix Cygwin tools and MKS ones at the same time won't generally work well, and is probably the cause of the shell problems too - MKS apparently is known to have problems under Win7. Gene, try removing MKS from your PATH setting. 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: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote: On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote: And the reroll failed to build because of the problem JonY ran into with java. Turns out that libjava keys off the presence of pthread_getattr_np (added to the DLL a few versions ago) to decide whether to invoke a couple of boehm-gc functions that only existed in pthread versions, so weren't implemented for win32 threads as used by the Cygwin port. I've added a patch that implements them and am starting again. As mentioned previously, I already fixed that in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc PLEASE use this as the basis for your packages; there are a number of important fixes in that patchset. Well, I was just going to do a quick update to 4.7.1-1, still as a test: version, in order to a) fix the dependencies and b) get exported TLS vars working, and then integrate all your extra patches before doing the first full curr: release. Is that not a good idea? b) in particular was important for getting new versions of mpfr to work without having to disable thread support. cheers, DaveK
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 02/04/2013 16:27, Achim Gratz wrote: I've added test packages compiled with gcc-4.7.2-1 (to be installed by manually selecting them, like the test version of gcc itself): wget=wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release; Is there some access permission I would need to take a look at those? $ wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release --2013-04-05 18:16:13-- http://cygwin.stromeko.net/release Resolving cygwin.stromeko.net (cygwin.stromeko.net)... 212.90.148.102 Connecting to cygwin.stromeko.net (cygwin.stromeko.net)|212.90.148.102|:80... co nnected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://cygwin.stromeko.net/release/ [following] --2013-04-05 18:16:15-- http://cygwin.stromeko.net/release/ Connecting to cygwin.stromeko.net (cygwin.stromeko.net)|212.90.148.102|:80... co nnected. HTTP request sent, awaiting response... 403 Forbidden 2013-04-05 18:16:16 ERROR 403: Forbidden. cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 05/04/2013 18:07, Dave Korn wrote: On 04/04/2013 10:13, Yaakov (Cygwin/X) wrote: On Sun, 31 Mar 2013 19:57:09 +0100, Dave Korn wrote: And the reroll failed to build because of the problem JonY ran into with java. Turns out that libjava keys off the presence of pthread_getattr_np (added to the DLL a few versions ago) to decide whether to invoke a couple of boehm-gc functions that only existed in pthread versions, so weren't implemented for win32 threads as used by the Cygwin port. I've added a patch that implements them and am starting again. As mentioned previously, I already fixed that in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc PLEASE use this as the basis for your packages; there are a number of important fixes in that patchset. Well, I was just going to do a quick update to 4.7.1-1, still as a test: version, in order to a) fix the dependencies and b) get exported TLS vars working, and then integrate all your extra patches before doing the first full curr: release. Is that not a good idea? b) in particular was important for getting new versions of mpfr to work without having to disable thread support. Also, c) I have a fixed libffi package to go with it, which would resolve the problems mentioned by Angelo G. in http://cygwin.com/ml/cygwin/2013-04/threads.html#00081 I really think it's worth uploading as a stop-gap. cheers, DaveK
Re: Problems with GCC-4.7.2-1 (test)
On 05/04/2013 12:22, Angelo Graziosi wrote: Just for completeness... This morning I have installed the test release of GCC-4.7 (4.7.2-1) and after that a few applications do not work any more. For example, Terminator, installed via Cygwinports, does not start. From command line I have: $ terminator You need to install the python bindings for gobject, gtk and pango to run Terminator. I have also a GTK-build of Emacs trunk and $ emacs -Q /usr/local/emacs/bin/emacs-24.3.50.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory This looks like the quickest point to try tracking it down. Does cygcheck on the exe show any missing DLLs? Reverting to GCC-4.5.3 all works fine. BTW, I did the Emacs build using CLANG (3.1, i386-pc-cygwin), so I don't understand much why the new GCC-4.7 interferes with Emacs. Did you install the manually-required runtime libs as well? 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: Problems with GCC-4.7.2-1 (test)
On 05/04/2013 20:52, Ryan Johnson wrote: On 05/04/2013 3:07 PM, Angelo Graziosi wrote: Dave Korn wrote: Did you install the manually-required runtime libs as well? I don't understand here. I have installed GCC-4.7.2-1 with setup.exe choosing Exp packages and then leaving only 4.7.2-1 for installation. Which runtime libs it needs? manually-required? Shouldn't test packages be installed only with setup.exe? I am confused now... :-( I think he means the other gcc-related packages in setup.exe; dependencies of test packages aren't tracked because they tend to pull in experimental versions of dependencies for non-experimental packages you might have installed. A shortcoming of setup.exe. I don't know which dependencies those might be, though... They were listed in the announcement: 2. Setup does not pull all required dependencies. This is done on purpose to allow the default 4.5.3-3 release to work out of the box. There are 3 new packages that should be noted if you install this version of gcc. libgnat4.7, libobjc4 and libquadmath0 for gcc4-ada, gcc4-objc and gcc4-fortran respectively. Probably not related, I guess. 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
[coreutils] Bug in du with -x flag?
Hi list, I always used to use du with the -cxhs options, but since updating to the latest (8.15-1) version there appears to be a problem caused by -x: $ ls -la total 392188 drwxr-xr-x+ 1 DKAdmin None 0 Apr 6 00:35 . drwxr-xr-x+ 1 DKAdmin None 0 Apr 3 05:58 .. drwxr-xr-x+ 1 DKAdmin None 0 Apr 3 16:28 gcc4 -rw-r--r-- 1 DKAdmin None 40157 Apr 6 00:43 gcc472-2-dist.tar.bz2 $ du -xh gcc472-2-dist.tar.bz2 $ du -h gcc472-2-dist.tar.bz2 383Mgcc472-2-dist.tar.bz2 $ Unless I'm misunderstanding it badly, -x shouldn't make any difference when counting a real file in the current directory. I wonder if it could have perhaps been introduced by the recent related bugfix that I read about in /usr/share/doc/coreutils/NEWS: du -x no longer counts root directories of other file systems. [bug introduced in coreutils-5.1.0] or perhaps some interaction between that and Cygwin's path conversion code? 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
cygport debuginfo problem: packaging fails.
Hi Yaakov et al.,
I'm confused by the output from cygport (0.11.3) when building GCC. During
the packaging step, after the final binary package from PKG_NAMES has been
tarballed, I see:
*** Info: No debug files, skipping debuginfo subpackage
Checking packages for missing or duplicate files
*** Warning: Packages are missing files:
-usr/lib/debug/usr/bin/c++-4.exe.dbg
-usr/lib/debug/usr/bin/cpp-4.exe.dbg
-usr/lib/debug/usr/bin/cygffi-4.dll.dbg
-usr/lib/debug/usr/bin/cyggcc_s-1.dll.dbg
I don't understand this. First it's complaining that there aren't any debug
files, so it won't package them, but then they actually are there after all
and it complains they haven't been packaged. That appears self-contradictory!
Any idea what might be causing this? Do I have to create -debuginfo
packages manually if I'm using the PKG_NAMES and (package)_CONTENTS variables?
Or could it perhaps be because the PN package itself has no contents at all,
serving only as a dummy to draw in dependencies through the requires: line in
its setup.hint? (In my cygport script, PKG_NAMES contains ${PN} but there
is no ${PN}_CONTENTS defined anywhere.)
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: cygport debuginfo problem: packaging fails.
On 01/04/2013 09:56, Dave Korn wrote:
Hi Yaakov et al.,
I'm confused by the output from cygport (0.11.3) when building GCC. During
the packaging step, after the final binary package from PKG_NAMES has been
tarballed, I see:
*** Info: No debug files, skipping debuginfo subpackage
OK, so this means that ${D}/usr/src/debug does not exist, and that's because
nothing was installed there by __prepdebugsrc(). That has something to do
with the fact that none of my source files got listed in ${T}/.dbgsrc.out, and
I think that in turn is because objdumping the built exes doesn't reveal any
paths to source files that begin with '/usr/src/debug'.
That seems to be because no -fdebug-prefix-map options got added during the
build stage. Or rather, the options did get added, but that was before
/usr/bin/cygport included my .cygport script, which went and unset them again.
I'm not sure why I originally included that any more, I left a comment about
how setting them in the environment confuses auto-detection process during
gcc build stages, which isn't as clear as I now wish, so I guess I'll just
delete that bit and try again. Looks like the problem is my fault, anyway;
pardon the noise.
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: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 28/03/2013 15:18, Dave Korn wrote: On 28/03/2013 14:05, Dave Korn wrote: Righto. Will upload as soon as I've finished running setup ;) Argh. Gotta re-roll the packaging step as I forgot to commit some of the setup.hint reversions to my local svn. D'oh, but at least I spotted it before uploading. And the reroll failed to build because of the problem JonY ran into with java. Turns out that libjava keys off the presence of pthread_getattr_np (added to the DLL a few versions ago) to decide whether to invoke a couple of boehm-gc functions that only existed in pthread versions, so weren't implemented for win32 threads as used by the Cygwin port. I've added a patch that implements them and am starting again. cheers, DaveK
Missing mime types lead to broken pages in the package list.
Hi folks, There are a lot of broken entries in the lower levels of the package list on the website. Clicking a package name at http://cygwin.com/packages/ takes you to the page that lists the available binary and source package versions, as before, but attempting to follow the link to one of the versions to see the package contents works for some packages, displaying a webpage, but for others triggers a file download dialog in your browser. A few examples: http://cygwin.com/packages/expat/ - broken http://cygwin.com/packages/fcgi/ - broken http://cygwin.com/packages/flawfinder/ - working http://cygwin.com/packages/gnupg/ - broken According to wget, the working links are being served up with text/html mime type, but the broken ones are coming down as application/x-troff-man. Fallout from the recent upgrade? 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: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 26/03/2013 11:20, Corinna Vinschen wrote: Hi Dave, On Mar 12 23:50, Dave Korn wrote: On 12/03/2013 22:15, Achim Gratz wrote: Achim Gratz writes: Yaakov (Cygwin/X) writes: OK. I won't be able to run the tests for some packages this way, but it sounds like this should provide a workable solution for bootstrapping. I guess we will anyway have to re-compile all packages with gcc47 when it is ready for release, right? Fascinatingly the tests for libmpc do run, although ldd gets confused about what libraries it depends on and stops midway after outputting a dependence on ?. If the second gcc47 test release is made within this week I'd prefer that to roll the packages, otherwise I'll set up a second installation with the current release. I'll put all packages for the gcc47 branch into [test], like gcc itself, is that correct? I haven't yet had an explicit go-ahead for that -2 release, but I've been rerolling it with the mpfr (shared libgcc) fix in order to be ready. Gonna check the same fix into upstream trunk tonight as well. How's the state of affairs? I've realised that I should re-roll the release after updating to the latest cygport, as I don't yet have the version with the debuginfo changes, which I assume are desirable? If that's not so important, I could upload the existing build today and then re-roll a -3 with debuginfo, does anyone prefer it one way or the other? cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 28/03/2013 13:39, Corinna Vinschen wrote: On Mar 28 13:25, Dave Korn wrote: I've realised that I should re-roll the release after updating to the latest cygport, as I don't yet have the version with the debuginfo changes, which I assume are desirable? Just run setup ;) If that's not so important, I could upload the existing build today and then re-roll a -3 with debuginfo, does anyone prefer it one way or the other? I'd be fine with a -2 without debuginfo for now. Righto. Will upload as soon as I've finished running setup ;) cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 28/03/2013 14:05, Dave Korn wrote: Righto. Will upload as soon as I've finished running setup ;) Argh. Gotta re-roll the packaging step as I forgot to commit some of the setup.hint reversions to my local svn. D'oh, but at least I spotted it before uploading. cheers, DaveK
Re: [PATCH] setup: port to 64-bit, part 1
On 04/03/2013 06:31, Christopher Faylor wrote: On Sun, Mar 03, 2013 at 09:54:58PM -0600, Yaakov wrote: Based on your recent commit to cygwin-64bit-branch, are we dropping support for Win2K as well? Yes. :-( Gonna have to set up a new dev environment on a new pc cheers, DaveK
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 12/03/2013 22:15, Achim Gratz wrote: Achim Gratz writes: Yaakov (Cygwin/X) writes: OK. I won't be able to run the tests for some packages this way, but it sounds like this should provide a workable solution for bootstrapping. I guess we will anyway have to re-compile all packages with gcc47 when it is ready for release, right? Fascinatingly the tests for libmpc do run, although ldd gets confused about what libraries it depends on and stops midway after outputting a dependence on ?. If the second gcc47 test release is made within this week I'd prefer that to roll the packages, otherwise I'll set up a second installation with the current release. I'll put all packages for the gcc47 branch into [test], like gcc itself, is that correct? I haven't yet had an explicit go-ahead for that -2 release, but I've been rerolling it with the mpfr (shared libgcc) fix in order to be ready. Gonna check the same fix into upstream trunk tonight as well. cheers, DaveK
Re: GCC 4.7 and dependencies
On 11/03/2013 23:40, Yaakov (Cygwin/X) wrote: JonY, Achim, and others, I have updated .cygport and patch files for GCC and its dependencies: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc I'm trying to look at this, but all I get is errors: $ git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/gcc4 Cloning into gcc4... fatal: The remote end hung up unexpectedly $ Is there something wrong with the format of the git: URL I'm using? cheers, DaveK
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 10/03/2013 15:43, Achim Gratz wrote: - TLS disabled since it doesn't work with current gcc I just debugged that over on the mpfr list. It can be made to work by adding LDFLAGS=-shared-libgcc to your configure line. (I'm going to patch upstream GCC to make that the default, and I'm also rolling a 4.7.2-2 with that patch included.) cheers, DaveK
Re: Why libquadmath0-4.7.2
On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. If it would help, I could upload a 4.7.2-2 later tonight which restores java and has the original 4.5.3-3 dependencies? (Many thanks to JonY for stepping up to the plate while I've been away.) 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: Why libquadmath0-4.7.2
On 11/03/2013 23:21, Christopher Faylor wrote: On Mon, Mar 11, 2013 at 06:03:08PM +, Dave Korn wrote: On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. Dave, I've pinged you on the -apps list and you haven't responded. How recently? I've got a backlog of 2400 unread mails there (and 8682 mails here). Yes, I've been away, but I can now commit to being back on the case; the project I've been working on for the past god-knows-how-long is done. I've already got back to work on upstream GCC and would like to get back to work on Cygwin. 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: Why libquadmath0-4.7.2
On 11/03/2013 22:12, JonY wrote: On 3/12/2013 02:03, Dave Korn wrote: On 05/03/2013 16:22, Christopher Faylor wrote: On Tue, Mar 05, 2013 at 05:11:34PM +0100, Angelo Graziosi wrote: I have GCC-4.5.3 installed and I am not going to install the test version 4.7.2-1, but setup.exe *wants* to install libquadmath0-4.7.2-1 even if I have selected Curr packages (which should exclude any reference to 4.7.2 version...). Have we sure it isn't a packaging bug? The crude dependency handling in setup.exe isn't up to the task of allowing per-version dependencies. So this probably came along because it's required for a newer version of gcc. When last we spoke (on the -apps list), it was suggested that the dependencies should remain correct for the curr: version, and people installing the test: version should manually install the required dependencies. If it would help, I could upload a 4.7.2-2 later tonight which restores java and has the original 4.5.3-3 dependencies? You'll be retaking maintainership again? I don't mind that, but please push as much of the patches as possible upstream, it was kind of hard to wrap my head around the patches to manually apply them. I would like to resume maintaining it, subject to any discussions necessary. Being an upstream maintainer makes it easier for me to push patches. 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: Weird threading / __thread behavior
On 18/02/2013 11:59, Ryan Johnson wrote: On 17/02/2013 10:38 PM, Zach Saw wrote: The following test case fails on Cygwin but passes on Linux (both tested using GCC 4.7.2). Cygwin doesn't have a gcc-4.7.2 package yet (not even for testing); 4.5.3 is the highest I see this morning in setup.exe. Sorry gang, I've been on hiatus. I have almost got 4.7.2 GTG, and I'm starting to pay some attention to GCC trunk again. 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
Changing dependent library version numbers vs. test packages vs. requires: lines.
Hi all, I've got a gcc-4.7.2 package almost ready to upload, but there's one issue I'm not sure what's best to do about. Several of the runtime libs have changed version numbers, i.e. libgnat4.5-libgnat4.7, libgcj11-libgcj13, libobjc2-libobjc4. I'd like to release a test: version of the new compiler, but I don't know what's best to do for the requires: lines in the setup hint files. If I add the new library versions, those dependencies will also be pulled in by people installing the curr: version of the compiler, but the new libraries won't exist in curr: versions. If I don't, people installing the test: version will have to ensure they manually select the new runtime libraries, which might be the least worst option. Is there any better way to handle this situation? cheers, DaveK
Re: Mingw64 and Cygwin: header and libs layout
On 13/03/2012 10:10, Corinna Vinschen wrote:
For the time being, I'm using the -idirafter flag to include the Mingw64
headers into the search path, but that's IMHO not a generic solution for
a (yet to create) Cygwin 64 bit GCC.
The generic solution for the future cygwin64-targeted GCC will of course be
to not refer to the mingw64 headers at all!
On 13/03/2012 13:51, Christopher Faylor wrote:
On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
On Mar 13 14:25, Kai Tietz wrote:
I suggest the approach to install for cygwin the platform-headers to a
shared place. I suggest that mingw-w64 adds to configure for headers
and crt an option, which installs platform-headers/libraries to
'/usr/shared/psdk_windows' location. Means under this path are the
folders lib/lib64/include containing only the platform-parts.
That sounds like an excellent idea to me!
For the cygwin-based mingw-w64 cross-compiler we need to add here by
spec (for headers in gcc and for libs in binutils or gcc). IMHO this
should be a special configuration option for gcc (and binutils), which
adds the required parts to spec-files.
IMHO we should keep the w32api scheme. The reason is that this
requires no changes at all to the gcc specs file. Rather, the Cygwin
gcc package would simply create matching symlinks:
ln -s /usr/share/windows_psdk/include /usr/include/w32api
ln -s /usr/share/windows_psdk/lib /usr/lib/w32api
ln -s /usr/share/windows_psdk/lib64 /usr/lib64/w32api
I think it's pretty unusual to install libraries and headers in
/usr/share, particularly in the case of libraries. gcc/linux has
conventions for this type of thing. I broke them when I installed
headers and libraries in /usr/include/w32api. I don't think we should
stray further by putting things in /usr/share.
Could Dave Korn weigh in on this?
I'd find it a bit odd as well, but can't really think of an actual problem,
it just gives me a mild bit of cognitive dissonance. It's an unusual
situation to want to share a set of headers but not the corresponding libs,
and doesn't work well with the standard $prefix/{lib,include} pattern. The
headers for w32api aren't huge in terms of disk space (5.5M), so just having
duplicates in the appropriate places wouldn't be that bad. It's what happens
every time you build libwhatever for both your native system and a
cross-target anyway.
Is there ever any likelihood that the w32api team might want to implement
autoconfigury-based customisations to the installed headers based on the
detected properties of the host platform (n.b. using 'host' in the library
sense, i.e. the same as 'target' for the compiler)? Sharing them between the
two compilers would lock that out.
(BTW, I noticed that gcc 4.7.0 was released, so I'll try and get a test
package up over the next fortnight or so).
cheers,
DaveK
Re: Mingw64 and Cygwin: header and libs layout
On 24/03/2012 19:19, Corinna Vinschen wrote:
On Mar 24 18:12, Dave Korn wrote:
On 13/03/2012 10:10, Corinna Vinschen wrote:
For the time being, I'm using the -idirafter flag to include the Mingw64
headers into the search path, but that's IMHO not a generic solution for
a (yet to create) Cygwin 64 bit GCC.
The generic solution for the future cygwin64-targeted GCC will of course be
to not refer to the mingw64 headers at all!
Huh?
Just like the current i686-pc-cygwin-gcc does not refer to mingw32 headers,
a future theoretical x86_86-pc-cygwin64-gcc will not refer to mingw64 headers,
because we'll have a proper native compiler rather than having to rely on a
cross-compiler that is almost - but not quite - correct.
Sorry, but I don't understand what you mean. Of course we would like
to share headers *and* libs. See above.
OK, then I clearly don't understand what you mean. Didn't this thread start
with you pointing out that, although the same headers were valid for cygwin or
mingw, the startup crt .o files and libs weren't right? How can the cygwin .o
files possibly be compatible with the mingw ones?
The include files are the
same for 32 and 64 bit, while the libs are obviously different.
So why do you want to share the libs, since they are different?
Therefore
it makes sense to create a shared directory which contains the shared include
files as well as the different libs for the different platforms.
Ah, well, not to me it doesn't. To me, what makes sense is
(headers+libs)*different.platforms, not (headers)*different.platforms +
(libs)*different.platforms, and this is what the entire GNU/Linux/Unix $prefix
structure assumes. I think this is a little bit like big-endian vs.
little-endian arguments: should the library itself be the most significant
part, or the target? Regardless the arguments one way or another, the GNU
system has already adopted the decision that $target is the most-significant
part of a $prefix layout.
My idea is to keep the w32api subdirs under /usr/include and /usr/lib,
and add a new one under /usr/lib64. These could be implemented as real
subdirs, or as symlinks to, for instance,
/usr/share/windows_psdk/{include,lib,lib64}, as outlined above.
The question is just where to keep the actual include and lib files in
this scenario, and Kai's suggestion was to keep them under
/usr/share/windows_psdk.
What you're implying there, is that from now forever onward, the cygwin
w32api and cross-mingw-w32api packages always have to be kept in perfect
lock-step, if there's only going to be one set of headers for two sets of
libs. That seems like a potential source of incompatibilities to me; as I was
trying to suggest in my comment about autoconfig-customised variants of the
headers, it may one day be the case that the headers for one set of libs have
to actually say something different from the headers for the other set of
libs, and we're tying our own hands in advance if we decide that one common
set of headers has to serve the same lib for two separate targets.
headers for w32api aren't huge in terms of disk space (5.5M), so just having
duplicates in the appropriate places wouldn't be that bad. It's what happens
every time you build libwhatever for both your native system and a
cross-target anyway.
So you opt for the current layout with duplicated include and lib files,
just with Mingw64 instead of Mingw32 files?
Yes, I think it's a perfectly acceptable compromise.
Is there ever any likelihood that the w32api team might want to implement
autoconfigury-based customisations to the installed headers based on the
detected properties of the host platform (n.b. using 'host' in the library
sense, i.e. the same as 'target' for the compiler)? Sharing them between the
two compilers would lock that out.
This is about using the Mingw64 headers, not the w32api headers from
Mingw32. And the 32 and 64 bit headers are the same. Platform
differences are handled via target macros.
Well, as long as we can *guarantee* for ever that that will always be the
case, we could indeed make some complicated scheme to share the headers work,
but really, for the sake of five meg of disk space, I don't see why it's worth
the risk or effort.
Let me summarise what I think: I think we should treat the x-cygwin
(==native) and x-mingw targets as if they were utterly entirely separate, just
like any two other random hosts/targets in the entire gnu infrastructure, and
simply not worry about one tiny disk-space optimisation that we could perhaps
make, at the expense of a good deal of other complications, some actual, some
potential. We should treat w32api as an external lib, and mingw should treat
it as their native C lib, and everything else should flow from that.
cheers,
DaveK
Re: gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin
On 07/03/2012 13:34, Ryan Johnson wrote: On 07/03/2012 8:07 AM, Corinna Vinschen wrote: On Mar 7 07:54, Ryan Johnson wrote: Hi all, I tried to bootstrap the gcc-4.7 RC and it fails because it expects to findprocess.h and the file actually lives in cygwin/process.h (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513). I'm asking here because the gcc devs thought this would mean 4.6 is broken as well, but I have 4.6.2 running. Did process.h perhaps move between 1.7.10 and 1.7.11? I guess configure must be using linker rather than preprocessor tests for presence of spawnve, because it thinks (correctly) that the function exists. See http://cygwin.com/ml/cygwin-announce/2012-02/msg00041.html We moved it back. If you have it in cygwin/process.h, you didn't update from 1.7.10 to 1.7.11. Ah, I do remember that, now that you mention, but I was running a 1.7.11 snapshot and forgot to upgrade... Thanks for the quick reply, Ryan Thanks for spotting that Ryan. FTR, I figure it's not worth delaying the GCC release to add a fix to support .10, since there were other significant problems with it, and anyone who has it should be moving to .11 anyway. 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: make producing basename error that can't be captured by make make.out
On 02/03/2012 02:52, Paul Allen Newell wrote: [ weird problem symptoms ] You probably have a script or shell alias getting in between you and the real make. Please run type make ; which -a make in a bash shell and show us the results. 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: [NEARLY SOLVED:] Re: make producing basename error that can't be captured by make make.out
On 02/03/2012 06:25, Paul Allen Newell wrote: +++ type make; which -a make make is aliased to `settitle Making $(basename $PWD) make $@' /usr/bin/make /usr/bin/make +++ I groaned when I saw this as it is obvious the $(PWD) is feeding basename and that's the make error. Thanks. However, I am still trying to understand why this potentially incorrect alias is creating text output to the screen which can't be redirected as it isn't stdout or stderr ... or 3/4/5 as someone suggested I test. I think it's because aliases are just simple text substitutions. So if you have 'make' being transformed to 'settitle Making $(basename $PWD) make $@' then you would get 'make make.out' becoming 'settitle Making $(basename $PWD) make $@ make.out' and as you see the redirect only gets applied to the command after the ''. 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: [SOLVED:] Re: make producing basename error that can't be captured by make make.out
On 02/03/2012 07:06, Paul Allen Newell wrote: I'll go and figure out some way to filter $(PWD) to be acceptable to basename. It just needs quotes around it to prevent the space being taken as a separator. 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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 27/02/2012 16:12, Paul Keir wrote: Thanks Dave, it's fixed. It looks like the problem was the cygwin1.dll in C:\Windows\SYSTEM. I have no idea why that was there. (I am not the first to use this machine.) Well, you may just find out when something else stops working - it's not unknown for people to ship custom toolchains built on Cygwin that install the DLL into the SYSTEM directory. (In which case, put the DLL you found there into the binaries dir alongside the tools involved.) As a precaution I have also removed C:\Users\\home\apps\gcc-4.7-20120128\bin from my PATH. I had built it with --program-suffix=-4.7, but the following potentially conflicting files remain there with their names untouched: cyggfortran-3.dll cygssp-0.dll cygstdc++-6.dll Although having them later in the path than the system versions in /usr/bin should in theory make that safe, mixing DW2 and SJLJ is asking for trouble to crop up somewhere down the line. 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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 24/02/2012 09:22, Paul Keir wrote: Hello, After installing a package (libxrandr-dev I think) GCC 4.5.3 (from Exp) has a problem. Even Hello World gives me: hello.c:1:0: fatal error: can't open /tmp/ccc6IHTT.s for writing: No such file or directory compilation terminated. I have tried reinstalling GCC with no luck. Can anyone offer advice? Is the drive where your /tmp dir is located full? Does it have the right permissions? Can you create the same named file manually (e.g. run a command like ls /tmp/ccc6IHTT.s)? If none of that sheds any light on it, please run cygcheck -s -v -r cygcheck.out and send that file **as an attachment only please** with your next post. Also, re-run the gcc compile command that's failing, but add the -v option to the command-line, and show us all the output it generates. 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: strange bug that doesn't occur in Linux, OpenBSD or ITS
On 18/02/2012 18:32, Jeremiah Bishop wrote: the bash commands used are: 1) gcc cygwin puzzle.c 2) ./a.out a b Now either version used on a file with a shorter set of lines, works just fine but strangely, that single digit difference aborts the program without throwing any error on the sample input or text files with similarly long lines. Your program is overflowing the stack. The default amount of stack space allocated by windows for a program is 2MB, but you can increase it using the -Wl,--stack,SIZE option (GCC passes -Wl options through to the linker, see 'man ld' for details of the --stack option). I found your program could run to completion when I compiled it with -Wl,--stack,1000 for a ~10MB stack. However the better fix would not to be to nest forty-three thousand recursive stack calls. Your code is very slow because it starts at the beginning of the list every time and recursively works its way to the end, costing a function call and stack frame for every node along the way. Iterate if you really have to do it that way, or even better, keep a pointer to the end node of the list and just go straight there. 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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 24/02/2012 13:52, Paul Keir wrote: Thanks. No, it's not full. The permissions are: drwxrwxrwt+ 1 Paul root 0 Feb 24 13:36 tmp and I can create the same file manually. Oh well, always worth checking the basics first, but no real surprise! The output of gcc -v hello.c is attached. I am running Windows 7 Professional - Service Pack 1. I'm afraid I can't send the output of cygcheck to the mailing list for confidentiality reasons. I could either send it to you directly, or perhaps run cygcheck in a way to generate less data. If you're that worried I don't mind if you'd rather send it to me offlist, go ahead, but it's not like you know me well enough to trust either, so I'd suggest you redact any sensitive data (user names? passwords in environment vars?) before posting it either way. By the way I get the following errors from cygcheck, only when I redirect the output: /usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'ose': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'osppsvc': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'pla': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'QWAVE': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcEptMapper': Win32 error 5 Access is denied. /usr/bin/cygrunsrv: warning: OpenService failed for 'RpcSs': Win32 error 5 Access is denied. That's not unexpected if you're running under a non-administrative account. There was nothing unusual in the output from gcc -v. If the cygcheck output doesn't show anything, I'll have to get you to run cc1.exe under strace. However, before we do that, there's one other thing I forgot to ask: what's the exit status after gcc fails? echo $? should show it, assuming you're using bash. 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: GCC fatal error: can't open /tmp/ccc6IHTT.s for writing
On 24/02/2012 15:36, Paul Keir wrote: echo $? returns 1 after using gcc. Right, that's helpful of it! That's clearly just a fail status but not an errno value. Anyway, I think your cygcheck reveals the problem. You have multiple cygwin1.dlls of different versions in your path at the same time. You also have a homebrew build of gcc 4.7 in your path, and it's using SJLJ exceptions rather than DW2, which means that its runtime DLLs will be incompatible with the standard system ones. Try removing the cygwin1.dll from C:\Windows\SYSTEM, and cutting C:\Users\\home\apps\gcc-4.7-20120128\bin out of your PATH, and see if that fixes it. 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: Spawning Java from C
On 24/02/2012 15:07, Eliot Moss wrote: On 2/24/2012 9:57 AM, Jim Rome wrote: Larry Hall (Cygwinreply-to-list-only-lhat cygwin.com writes: To the OP, run the same from an elevated prompt and these errors should disappear. I tried it also with windows style paths, both using \\ and / as separators with the same results. What does to the OP mean? And are you implying it has to be run as an administrator? MinGW does not require that. OP = Original Poster (see the cygwin standard acronyms :-) ) Yes, the responder *is* saying that you need to run this as administrator. No. He was saying that if you run *cygcheck* from an elevated prompt, you won't get the Can't open service errors. 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: Automating setup - --no-verify doesn't seem to work
On 24/02/2012 19:56, Andrew DeFaria wrote: I'm trying to automate the setup of cygwin and I'm running setup.exe with many additional options. All in all it's working fairly nicely but the --no-verify doesn't seem to work. The help says that --no-verify is Don't verify setup.ini signatures yet when I run it I see a lot of Checking MD5 for package. Isn't there an option to turn off this MD5 checking? No, those are actually two separate things. The --no-verify option means that setup.exe will accept any setup.ini file with any values for the md5sums for packages, not just the official version; it doesn't stop the md5sums from being checked, just means that a custom mirror can supply its own versions of packages with their own md5sums, but they always get checked no matter what. 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: cygport: broken vs. autotools by set -e
On 20/01/2012 12:50, Andy Moreton wrote: On Thu 19 Jan 2012, Dave Korn wrote: Commenting-out the set -e; line at the start of /usr/bin/cygport has fixed this problem, and my builds now run just fine, but huh? I checked in git; that line has been there since like forever, so why is it giving me trouble now? Is there something I could have changed in my environment or startup scripts that is causing this -e to propagate to subshells that it didn't used to, or did there used to be a mechanism in cygport that would have had the effect of turning it off for subshells that has now been removed for some reason? Hi Dave, As a WAG it could be that you have differences in behaviour from updating bash - check the docs for 'set -e' changes in bash 4.x Hi Andy, Bash wasn't one of the packages updated - we've been on bash 4 since February last year, and I already had it installed last september when I was successfully using cygport to build the gcc-4.5.3-1 release. So I figure that the 4.x set -e behaviour might be part of this problem, but there must have been a change in cygport that's exposing it when it was previously hidden. cheers, DaveK PS. Hope everything's well with you and happy new year! We should arrange a pub meet sometime soon on the pig list. -- 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 Configuration
On 18/01/2012 19:49, Ashlar wrote: I have cygwin installed with a number of directories named following this format: C:/Documents\040and\040Settings/Administrator/_web/crhub /webroot ntfs binary,posix=0 0 0 When I use the Mount command it includes the assignment for the line When I enter 'cd /webroot from the command line I get an error message 'bash: cd: /webroot: no such file or directory' These directory names worked until I deleted the path in .bash_profile accidentally. Now these pathnames are no longer recognized. I have tried to rewrite the Path=$path... line in the file .bash_profile, but do not know what to include in it. My windows path is being loaded and contains paths for C:/cygwin, C:/cygwin/etc/ and the absolute paths for the /webroot directory. Any suggestions are appreciated. There are default copies of a lot of these sorts of installable scripts under /etc/defaults. You'll find the original .bash_profile at /etc/defaults/etc/skel/.bash_profile. (Note that that's a default for the version that goes into /etc/skel, which is the 'current' one that's then used to set up new home dirs the first time a user runs the cygwin shell.) 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
cygport: broken vs. autotools by set -e
Hi list, I just updated my Cygwin installation for the first time since Oct 26 last year, and now I'm unable to successfully run cygport builds any more. The builds fail because of the spontaneous exiting of one or other of the scripts that cygport invokes - I've had autoconf-2.68 spontaneously exiting during the autoreconf stage, and if I skip over that the configure scripts do the same thing. On closer inspection, it turns out that they were exiting first time they executed subcommands that failed. I added 'set -o' to my cygport script, both inline so it would be executed when the script gets sourced, and inside my override of src_compile so I could see what was happening just before the configure call, and sure enough it showed me that errexit was off at the start of the run but had been set on by the time execution reached src_compile. Commenting-out the set -e; line at the start of /usr/bin/cygport has fixed this problem, and my builds now run just fine, but huh? I checked in git; that line has been there since like forever, so why is it giving me trouble now? Is there something I could have changed in my environment or startup scripts that is causing this -e to propagate to subshells that it didn't used to, or did there used to be a mechanism in cygport that would have had the effect of turning it off for subshells that has now been removed for some reason? 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: hard-coded library search path in gcc-4
On 20/01/2012 04:07, Ilguiz Latypov wrote: I found that gcc-4 from a recent setup.exe could not start cc1 because the latter could not find some shared object file. I confirmed that by running cc1 alone with an empty PATH variable. Running cygcheck /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe should show you what library is missing. Setup.exe should have considered all the dependencies but maybe we've got a bug or a missing one somewhere. 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: Bad address error with redirection (stdout and stderr) in background process
On 16/01/2012 06:47, Heiko Elger wrote: Dave Korn gmail.com writes: looks like there was a second snapshot later the same day that replaced the one you had installed. That's it! Thanks a lot .. I never see a snapshot released twice a day Just one question: How can I figure out whether a snapshot is released more than once a day? Well, if ... - you download a snapshot - you find a bug - you report it and discuss it on the list - cgf says he's just created a snapshot to fix your bug ... you can infer by pure logic alone that he's not talking about the snapshot that was uploaded *before* you reported your bug. You can also look at the hours and minutes in the timestamp listed on http://cygwin.com/snapshots/ as well as the date and compare it to the one you downloaded earlier in the day. 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: Bad address error with redirection (stdout and stderr) in background process
On 15/01/2011 19:41, Heiko Elger wrote: Christopher Faylor writes: If you are saying that the problem is not fixed in the most recent snapshot then please clearly say that. Otherwise, I don't understand what you are asking. I sent my email on January 11 shortly before the January 11 snapshot was uploaded. There is no reason for you to expect a newer snapshot than that. In my first posting concerning this problem I posted tne used snapshot too (20110111) I'm using latest snapshot and updated cygwin installation. $ uname -a CYGWIN_NT-6.1-WOW64 PCFX166 1.7.10s(0.259/5/3) 20120111 01:45:50 i686 Cygwin I've done rebaseall and peflagsall. So I already used teh snapshot of January 11th. http://cygwin.com/snapshots/ currently says 2012-01-11 22:44:48 UTC, so it looks like there was a second snapshot later the same day that replaced the one you had installed. 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: trouble with cgreen test runner in cygwin
On 13/01/2012 02:16, Matt wrote: the test-runner discovers the tests correctly, but when it goes to run them, it fails. this is because the CgreenTest* we fetch via dlsym() appears to be corrupt. We'll reduce it to an even smaller, self-contained test case tomorrow. If anyone has ideas/suggestions in the meantime, please let me know. Without having even looked at the code, here's one thing worth verifying: make absolutely certain that the pointer-to-function type you're dereferencing the pointer returned from dlsym() as has exactly the same calling convention as the function definitions do when you're compiling them into the DLL. 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: Can't get includes untangled
On 10/01/2012 19:25, Larry Hall (Cygwin) wrote: On 1/10/2012 2:17 PM, Jarome wrote: When I make my Windows 7 cygwin project, I keep getting In file included from /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../ include/w32api/windows.h:98:0, from src/tkfPusher.c:23: /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/ winsock2.h:103:2: warning: #warning fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets Everything works in MinGW. Don't include windows files for Cygwin. Think of Cygwin as a UNIX/Linux environment. Anything you wouldn't include there shouldn't be included when building for Cygwin. That's a simple rule to follow that will avoid some problems, but I thought mixed-mode coding wasn't actually prohibited and we don't actually go out of our way to break it - hence the existence of __USE_W32_SOCKETS in the first place, no? To Jarome: I tried adding the #define __USE_W32_SOCKETS to try and fix this because if defined, it should ignore the fd things in types.h, but no success. The problem is that you're not defining it early enough: #define GPC_CYGWIN #define GPC_WIN #include stdio.h #include errno.h #include dirent.h // This includes sys/types.h Yes, it does, so __USE_W32_SOCKETS should already have been defined by that point or it's too late; both winsock2.h *and* sys/types.h have to be #included while it is already in effect (they both contain #ifdefs that test it). And in fact, stdio.h also indirectly include sys/types.h, so the simple answer is just to define __USE_W32_SOCKETS right at the top alongside the other defines before you even include the first file. 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: Cannot implement -x switch for diff
On 12/01/2012 09:17, Fergus wrote: Hello, I want to compare the contents of two large directories whilst omitting two subdirectories console5/ and console7/ common to both. But using any combination of diff -rq /d1 /d2 -x console diff -rq /d1 /d2 -x console. diff -rq /d1 /d2 -x console./ That's regex notation. Have you tried a glob pattern instead? 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: same old problem, C compiler cannot create executables
On 31/12/2011 23:51, Douglas Pardoe Wilson wrote: Searching, I have found many people on many forums complaining that Cygwin produces a C compiler cannot create executables messaage. As so many people have reported, the config.log file contains nothing useful. Surely after all these years people should have a real solution to this problem. You haven't quite understood what you've been looking at. Your searches will have shown you that error message cropping up many times (on every platform that uses configure scripts, not just Cygwin), because this is the way configure reports /any/ problem that prevents it working out how to drive the compiler. However it's not one single problem at all: it's one symptom that can be caused by many different underlying problems, and almost every time the config.log file does contain enough information to diagnose the problem, or failing that to reproduce it at the command-line for further investigation. Among the many underlying problems that can cause this message to be reported are environment and configuration problems, such as having the PATH wrong or not having GCC installed, disk full errors, incorrect permissions, missing libraries or dependencies, and bugs or non-portable assumptions in the configure script templates for individual projects. It would probably be possible to improve autoconf so that it could generate configure scripts that try and diagnose some of the more common sources of problems running the C compiler, and perhaps be able to emit more helpful error messages in some cases, but in the majority of cases it's going to require manual intervention to diagnose and solve anyway, and as things stand configure just throws up its hands and says I give up. You figure it out. Are you experiencing an occurrence of this problem yourself right now in the course of building something, or was this just a general observation? It is unfortunate that, because this one error message is generated for so many different reasons, it's not easy to know when googling a solution whether the one you've found is related to what's gone wrong in your particular circumstances or not. 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: SHELLOPTS=igncr and bash --posix
On 30/12/2011 12:41, Rafael Kitover wrote:
On 12/30/2011 1:06 AM, Dave Korn wrote:
On 29/12/2011 21:40, Rafael Kitover wrote:
Some of my bash scripts, particularly ones that are #!/bin/bash --posix
trigger a nasty warning when I have SHELLOPTS=igncr set in my ~/.zshrc:
rkitover@eeebox ~/src/scala % echo $SHELLOPTS
igncr
rkitover@eeebox ~/src/scala % bash --posix
bash: SHELLOPTS: readonly variable
this is rather unsightly so I have turned off SHELLOPTS for now.
Is this a bug?
Bug in your script I'm afraid. SHELLOPTS is indeed a readonly variable, it
can only be set outside bash before starting it, definitely not from within a
startup script. (Perhaps the reason it seems associated with --posix is
because that selects different startup files? I'm guessing that you may have
ENV=~/.zshrc because it's not normal behaviour for bash to read zsh's startup
file!)
I don't have ENV set.
If I comment out the SHELLOPTS setting in ~/.zshrc then do this the
problem still appears:
rkitover@eeebox ~ % export SHELLOPTS=igncr
rkitover@eeebox ~ % bash --posix
bash: SHELLOPTS: readonly variable
%{
%}(%n@%m)[%h] %{%}%~%{%}
$
I do not have a ~/.profile, and ~/.bash_profile just reads ~/.bashrc. I
do not set SHELLOPTS in ~/.bashrc, it only has set -o igncr.
Ah, I'm guilty of trusting the documentation too much. Turns out the
problem is easy to reproduce without zsh being anything to do with it: even if
you have SHELLOPTS set in the Windows environment and launch bash directly
from cmd.exe, it still fails -
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\Documents and Settings\Administratorset | grep SHELLOPT
SHELLOPTS=igncr
C:\Documents and Settings\Administratorbash --posix
bash: SHELLOPTS: readonly variable
bash-4.1$
A bit of googling and I discovered this is apparently a known bug in
upstream bash, reported on the GNU bug-bash list back in October at
http://lists.gnu.org/archive/html/bug-bash/2011-10/msg00039.html. A fix is
promised for the next release but until then I'm afraid you're stuck with only
being able to use one of SHELLOPTS and --posix at a time.
If so, is a fix possible?
Use set -o igncr instead.
But if I want to use CRLF #/bin/sh scripts from zsh, then I have to set
SHELLOPTS.
You might be able to make it work by setting ENV (would be BASH_ENV, but
you're using --posix) to point to a (LF-endings-only) script that contains
set -o igncr. Hopefully that will take effect before the newly-launched
bash has a chance to get upset by any CRs in the script file it's been invoked
on. (I can't guarantee that nothing will go wrong while parsing the shebang
line if that ends with a CRLF, but you may as well give it a try.)
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: SHELLOPTS=igncr and bash --posix
On 29/12/2011 21:40, Rafael Kitover wrote: Some of my bash scripts, particularly ones that are #!/bin/bash --posix trigger a nasty warning when I have SHELLOPTS=igncr set in my ~/.zshrc: rkitover@eeebox ~/src/scala % echo $SHELLOPTS igncr rkitover@eeebox ~/src/scala % bash --posix bash: SHELLOPTS: readonly variable this is rather unsightly so I have turned off SHELLOPTS for now. Is this a bug? Bug in your script I'm afraid. SHELLOPTS is indeed a readonly variable, it can only be set outside bash before starting it, definitely not from within a startup script. (Perhaps the reason it seems associated with --posix is because that selects different startup files? I'm guessing that you may have ENV=~/.zshrc because it's not normal behaviour for bash to read zsh's startup file!) If so, is a fix possible? Use set -o igncr instead. 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: Sorry people (NOT MY taxonomy!!), but igncr IS flawed
On 19/12/2011 17:35, Andrey Repin wrote: Greetings, Dave Korn! Windows GUI-based archivers are well known for causing this problem. To be fair, you should reduce your reference to WinZIP is known for. At the very least, WinRAR and 7-Zip, both won't try to hold your hand in this case. I don't know about WinACE, though, and I'm not going to check it myself. I haven't checked, but would bet WinRAR and 7-Zip don't accurately recreate the posix permissions when they unpack a *nix tarball. They probably don't unpack device nodes right either. They can probably get softlinks right but I haven't tested that either. Rather than play guessing games about which gui-based unpackers will do a good job of unpacking something into a Cygwin environment and have to repeatedly re-solve the problems they may cause every time someone says Oh, well you said not to use WinZip, so I used WinRAR (or whatever) instead, I just err on the side of caution and simply advise: for unpacking stuff into a Cygwin environment, always use a Cygwin-aware tool. 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: 16 byte pthread stack alignments
On 21/12/2011 09:42, Corinna Vinschen wrote: But OTOH I have to admit that I don't see how this alignment business worked at all. Aligning the stack to 16 byte in mainCRTStartup doesn't guarantee that the stack is still 16 byte aligned in main(). If that worked so far, it seems like a miracle. The call stack looks like this: mainCRTStartup - cygwin_crt0 - _dll_crt0 - _main_tls-call - _main_tls-call2 - dll_crt0_1 - main Every function on the stack changes the stack pointer. How did that work? Coincidence? And then again, isn't it gcc's job to make sure that the generated code makes sure the stack is correctly aligned for certain opcodes? What am I missing? GCC assumes that the stack starts off 16-aligned when the OS hands over to the exe's entrypoint, and then makes sure it stays that way by always rounding stack frame sizes up to the nearest multiple of 16. Or at any rate that's how it's supposed to work. 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: Sorry people (NOT MY taxonomy!!), but igncr IS flawed
On 17/12/2011 15:50, manu0507 wrote: - the script causing trouble comes in the GNU gdb distribution gdb-7.3.1.tar.gz Hah! I know what's happened: you used a windows program such as winzip or similar to unpack the archive, and it's gone and helpfully munged all the line endings for you. Use 'tar xvfz gdb-7.3.1.tar.gz' at the Cygwin shell command-line and you'll get a correctly unpacked version. (There definitely aren't CRLFs in the upstream release of the configure scripts.) Windows GUI-based archivers are well known for causing this problem. (Also, if you think that Eric's reply was acrimonious, you're just having some sort of using-language-in-different-ways communication problem. I saw it earlier and it seemed perfectly polite and proper to me, I honestly can't see what about it would offend you.) 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: rcs 5.8-1 corrupt files?
On 11/12/2011 08:24, Jay E. wrote: Suspected line-ender problem. Started over and used 'flip' to go with unix line-ender. Same problems. BUT it looks like the DOS lime ender was added after the flip by ci, or co. It looks like the line-ends are getting flipped in the actual RCS/*,v file, and that's probably because of your current directory: Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS 64999Mb 44% CP CS UN PA FC Preload d: cd N/AN/A C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive usertext,posix= Your /cygdrive is set to text mode, so when RCS tries to create files under that part of the tree, they'll get DOS CR-LF line endings. (This presumably reflects an underlying portability bug in RCS itself: it must not be using the b file mode in open calls. On Linux and Unix systems, binary mode is the same as text mode, but that isn't true everywhere, and even though it doesn't make a difference on those systems, the code should still correctly use binary or text mode when it opens a file according to the semantics of what it's going to write there.) You should be alright if you only use RCS inside other cygwin paths except for those under /cygdrive, or if you remove the text mode setting from your cygdrive prefix. 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: cyg*.dll, linking
On 13/12/2011 20:32, Warren Young wrote:
On 12/13/2011 12:18 PM, Brian Craft wrote:
On Tue, Dec 13, 2011 at 11:16 AM, Csaba Raduly wrote:
On Tue, Dec 13, 2011 at 7:45 PM, Brian Craft wrote:
And why don't I see cyg*.dll files, for example, in /usr/lib?
They are all hiding under /usr/bin :)
Ah! I see. So the install is working fine, I was just adding the wrong
directory to PATH, having no idea that libraries would be installed
under ${prefix}/bin. :)
Well, /usr/bin should be on your PATH at all times anyway...
...and that is on purpose, because of Windows' DLL search path rules:
http://msdn.microsoft.com/en-us/library/7d83bc18.aspx
If autotools generated Makefiles that installed DLLs in /usr/lib, you'd
have to add c:\cygwin\lib (or whatever) to the PATH, and then risk being
sent to DLL Hell by having another DLLs with the same name elsewhere in
the PATH.
What he said. It's a difference between Linux and Windows that we don't try
to hide: on Windows, executables don't contain an rpath (a path pointing to
where the needed shared libraries can be found at runtime) and there is no
equivalent of LD_LIBRARY_PATH for the Windows kernel file loader, so since
DLLs have to go on the PATH we install them to /usr/bin alongside the
executables that need them. /usr/lib still contains all the static libraries,
import libraries and associated libtool control files as normal though.
Also, from your original post:
building. Most of them build via autotools. Doing make install
installs files *.a, *.la, *.dll.a. Linking the executable succeeds
without error, however when running it, the loader complains that it
can't find cyg*.dll files. E.g. if it was libfoo.a that was installed,
the executable wants cygfoo-6.dll to run.
These cyg-*.dll files exist in the build directories, generally in
src/.libs . The program will run if I add all of these to the PATH.
Windows can only find DLLs if they are on the PATH (or in the same directory
as the executable being launched). Libtool is aware of this: if you look in
your build directory, in the src/ dir just above src/.libs, you'll find
something that looks like your executable but in fact isn't. The real
executable lives in the .libs subdir too, and the one by the same name in the
main build dir is a wrapper that sets the PATH to include any required .libs
directories and then invokes the real executable in the .libs subdir.
When you run make install, libtool copies the real executable into your
/usr/bin dir, the wrapper is no longer required at that point. (You can
control where the DLLs get installed by passing libtool the -bindir option,
should the default not suit you for any reason; the default is that DLLs go
into ../bin/ relative to the lib/ subdir where the .a and .la files go.)
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: fortran open mpi - getting mpif77 and mpif90 to work
On 14/12/2011 13:20, Jon Clugston wrote: On Tue, Dec 13, 2011 at 5:16 PM, Stitchz jsama...@gmail.com wrote: This is what I get on a fresh, default install of cygwin: $ mpif77 --- The Open MPI wrapper compiler was unable to find the specific compiler ifort.exe in your PATH. Note that this compiler was either specified at configure time or in one of several possible environment variables. --- So for some reason writing mpif77 on the command line does not result on a bash: command not found error. For some reason the command is referenced, even though it doesn't work out of the box. Maybe, you have an executable called mpif77 installed on your system, in your PATH, that isn't from Cygwin. The fact that the official Cygwin package list (http://cygwin.com/packages/) doesn't include anything containing even the substring 'mpif77' suggests that's pretty likely. 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: Issues with TCP Window Scaling Factor and Cygwin Daemons
On 15/12/2011 05:23, Lee wrote:
On 12/14/11, David Groves wrote:
I am having some issues with cygwin applications (specifically sshd)
and TCP Window Scaling Factors. I am using OpenSSH client on either a
Debian Linux or FreeBSD machine to connect to sshd on a Windows 2k8 R2
^^
server.
No pointers, but it does look like a Cygwin problem.
Start up wireshark on a Windows XP machine and ssh (from a cygwin
^^
window) to another machine - tcp syn packet has a window size of 65535
and a widow scale of zero. Use putty from the dos prompt to ssh to
the same machine and that has a window size of 65535 and a window
scale of 2
1. MS completely replaced the networking stack in Vista/2k8 with their
so-called Next Generation TCP/IP stack, so you can't extrapolate from XP to
2k8.
2. On XP, window scaling is enabled by a registry setting, and when it is
in effect, Windows decides what scale setting to use by considering the
SO_RCVBUF size used when the connection is initiated. In that light, the fact
that Cygwin applications show a scale of zero is probably not unrelated to
this snippet of code from net.cc#fdsock():
/* Raise default buffer sizes (instead of WinSock default 8K).
64K appear to have the best size/performance ratio for a default
value. Tested with ssh/scp on Vista over Gigabit LAN.
NOTE. If the SO_RCVBUF size exceeds 65535(*), and if the socket is
connected to a remote machine, then calling WSADuplicateSocket on
fork/exec fails with WinSock error 10022, WSAEINVAL. Fortunately
we don't use WSADuplicateSocket anymore, rather we just utilize
handle inheritance. An explanation for this weird behaviour would
be nice, though.
(*) Maximum normal TCP window size. Coincidence? */
((fhandler_socket *) fd)-rmem () = 65535;
((fhandler_socket *) fd)-wmem () = 65535;
if (::setsockopt (soc, SOL_SOCKET, SO_RCVBUF,
(char *) ((fhandler_socket *) fd)-rmem (), sizeof (int)))
{
[ ... snip error handling ... ]
}
I would guess that a 65536 default would cause Windows to send a non-zero
scale in the SYN packet, but as the comment says, that created some other sort
of problem somehow.
3. On 2k8 (also Vista and 7), window scaling is no longer controlled by the
registry but enabled automatically, as part of a new feature called Receive
Window Auto-Tuning. I could not infer from any documentation that I could
find in ten minutes googling whether or not it still pays attention to the
initial SO_RCVBUF setting. It might be worth trying a custom build of the
Cygwin DLL with a 64k or 128k setting in place of 65535. Then again, it seems
there may yet be problems in this functionality, e.g. the known bug described
at http://support.microsoft.com/kb/983528; perhaps if the custom Cygwin DLL
doesn't help, that hot-fix might.
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
[patch,1.7.10] clock_setres returns zero
Hi folks,
I actually noticed this in 1.7.9, but looking at the source in CVS I can see
it's still present in 1.7.10. Here's the STC:
$ cat clockres.c
#include stdio.h
#include time.h
#include errno.h
int main (int argc, const char **argv)
{
struct timespec ts;
if (clock_getres (CLOCK_MONOTONIC, ts) 0)
{
fprintf (stderr, Bad: %d\n, errno);
return -1;
}
printf (%ld sec, %ld nanos\n, ts.tv_sec, ts.tv_nsec);
return 0;
}
$ gcc-4 clockres.c -o clockres -W -Wall -Wextra
clockres.c: In function 'main':
clockres.c:6:15: warning: unused parameter 'argc'
clockres.c:6:34: warning: unused parameter 'argv'
$ ./clockres.exe
0 sec, 0 nanos
$
This happens because on my PC, QueryPerformanceFrequency returns 251160,
so the following code in times.cc#hires_ns::prime()
freq = (double) ((double) 10. / (double) ifreq.QuadPart);
calculates freq correctly(*) as 0.39815257206561555. This means that the
resolution is less than a nanosecond, so hires_ns::resolution(), which is
where clock_getres gets the result from, ...
LONGLONG
hires_ns::resolution ()
{
if (!inited)
prime ();
if (inited 0)
{
set_errno (ENOSYS);
return (long long) -1;
}
return (LONGLONG) freq;
}
... truncates it to zero. (The libgfortran testsuite barfs on this.)
Although the resolution is too small to express in integer nanoseconds,
that's ok when it's used to calculate the actual time, because that is all
done in double precision before being truncated to integer, in
hires_ns::nsecs() here:
// FIXME: Use round() here?
now.QuadPart = (LONGLONG) (freq * (double) (now.QuadPart -
primed_pc.QuadPart));
return now.QuadPart;
So we'll calculate the correct time to the nearest nanosecond anyway. Since
that's the maximum resolution that we can return in a timespec from
clock_gettime anyway, I think we should just round up resolutions less than
1ns to pretend they're exactly 1ns.
winsup/cygwin/ChangeLog:
* times.cc (hires_ns::resolution): Don't return less than 1.
Tested by building the clean sources, copying the DLL and test executable
into a temp dir on their own and invoking it from cmd.exe, patching the source
and rebuilding the DLL, copying the new DLL into the temp dir and rerunning
the testcase to see 0 sec, 1 nanos. Didn't do a full install though. OK?
cheers,
DaveK
--
(*) - Apart from the fact that it's a period, not a frequency!
Index: winsup/cygwin/times.cc
===
RCS file: /cvs/src/src/winsup/cygwin/times.cc,v
retrieving revision 1.112
diff -p -u -r1.112 times.cc
--- winsup/cygwin/times.cc 3 Dec 2011 21:43:27 - 1.112
+++ winsup/cygwin/times.cc 12 Dec 2011 08:23:20 -
@@ -718,7 +718,7 @@ hires_ns::resolution ()
return (long long) -1;
}
- return (LONGLONG) freq;
+ return (freq = 1.0) ? 1ll : (LONGLONG) freq;
}
UINT
Re: gcc-4.5.3 segfaults wrt alloca
On 09/12/2011 20:36, Corinna Vinschen wrote: On Dec 9 12:41, Ryan Johnson wrote: On 09/12/2011 12:07 PM, Eric Blake wrote: On 12/09/2011 07:55 AM, Ryan Johnson wrote: On 09/12/2011 5:58 AM, Denis Excoffier wrote: I use the latest packages and cygwin snapshots. The problem described below began several snapshots in the past, around beginning of December. The following program, with static allocation of a reasonable amount of data, segfaults, maybe in alloca(). With a smaller size (eg 1) it's ok. With new/malloc (even with 100 times more) it's ok. With C or C++. 100% reproducible. unsigned int const SIZE = 689471; int foo[SIZE]; Reasonable? You're trying to stack-allocate 2.5MB of data. Don't do that -- stack sizes are 2MB or less in most operating systems. Besides, doing anything useful with a buffer that size would completely drown out the overhead of calling malloc. Not only that, but stack allocating more than 64k in a single function is a recipe for bypassing the guard page and causing windows to silently quit your program, rather than letting cygwin catch the guard page access and convert it to normal SIGSEGV handling. To be portable to all OS, you should never stack allocate more than 4k in a single function. It's kind of interesting: when I ran that test case with my home-brew gcc-4.6, its alloca() explicitly walks through the proposed allocation in 4kB increments to ensure that a stack overflow triggers SIGSEGV right away, rather than allow silent data corruption later. I don't know if older versions also do this, but maybe that's why it used to work and now doesn't work. alloca works this way for ages, as far as I know. 1. Yes, alloca stack probes. 2. GCC uses alloca in the prologue of functions that need big stack frames allocated, in order to gain just that functionality. 3. Windows will grow the stack for you automatically if you hit a guard page. 4. A lot depends on the luck of how your process initial space is laid out. When I run the testcase and breakpoint at main, $esp = 0x22cd2c; that's only just over 2 meg anyway, so there's no address space to expand the stack down into and the seg fault happens when alloca tries to probe reserved low memory addresses. If however (cgf's case?) the initial stack is higher up in the address space, windows will grow it automatically for you as your probes hit guard pages until you reach the final required size. 5. Setting the program's initial stack size larger by adding e.g. -Wl,-stack,400 to the compiler commandline ensures that the initial stack pointer is located somewhere that at least that much memory is available, and makes the testcase run OK for me where previously it was faulting. 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: Clean removal of cygwin from Win 2008
On 05/12/2011 11:45, Andrew Erskine wrote: Hi, I've been trying to configure cygwin sftp for the firstime on win 2008 now after several installations and botched attempts I'd like to remove the product and start again. Could some one please provide steps to remove from registry etc Full uninstall is covered in the FAQ at: http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all 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: injob version 1.3
Windows 7. Everything up to date. /arc/2build gcc -o injob injob.c /tmp/ccOdzsVZ.o:injob.c:(.text+0x87b): undefined reference to `__imp__NtQueryInformationProcess@20' collect2: ld returned 1 exit status What am I doing wrong? Needs -lntdll. Also, if obcaseinsensitive=0, the #include Tlhelp32.h should be all lower-case. 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
Out-of-office messages spamming list posters
Could a mod please unsubscribe acn1 AT cam DOT ac DOT uk? His mis-configured vacation reply is sending a duplicate in response to every single list posting, and this is apparently going to continue until further notice. 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: best way to prevent a cygwin build?
On 02/12/2011 09:47, Csaba Raduly wrote: On Fri, Dec 2, 2011 at 8:46 AM, Paul Allen Newell wrote: I am not happy with having to run two separate source trees and would like a way (as in best standard) to add something to any Maya makefile which will prevent execution if it is being compiled on Cygwin. The best I have been able to come up with is a check under each make directive, but that's alot of exceptions where I would think only one would be necessary. I searched the GNU make docs and googled for such, but the best I could see were bailout rules under a given make rule directive. I can find out whether I need to bail by the test ifeq (Cygwin, $(shell uname -o)) but can't figure out a way to have the makefile ask this question once for the entire set of make directives in it. ifeq (Cygwin, $(shell uname -o)) PLATFORM := CYGWIN endif Well, in this particular case: ifeq (Cygwin, $(shell uname -o)) $(error This project does not build in Cygwin) endif Can be placed anywhere in the makefile, no need to modify the build rules. 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: cygwin dlls needed to run binutils
On 23/11/2011 16:59, Ryan Johnson wrote: On 23/11/2011 11:47 AM, Surrounder wrote: Larry Hall (Cygwin) wrote: A cygcheck on 'ld' shows cyggcc_s-1.dll is pulled in as a result of a dependency on cygintl-8.dll. I don't see a dependency on cygz.dll but perhaps another tool from the package pulls that one in. I found out that the needed dll´s depend on the .\configure I do, is there a way to find out what options were used makeing binutils last time out of the binaries? I tried searching a list where I can maybe find info about what cygwin dll is used for what function in binutils. I suspect that --disable-nls would remove the dependency on libintl, but I don't know what would pull in libz. That'll probably be the support for zip-compressed debug info sections that was added to the mainline sources around this time last year. It can be disabled by passing --with-zlib=no to configure, or apparently also as a side-effect of --disable-nls (according to a quick reading of the configure scripts, I haven't tested.) 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: Rolling back to 1.6.x Subversion
On 18/11/2011 14:24, Csaba Raduly wrote: On 11/18/11, Warren Young wrote: On 11/17/2011 3:42 PM, Andrey Repin wrote: [ one level of attribution lost here ] $ ls -d .svn 1.7 working copy do not have .svn dirs in nested directories. http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng Sorry, I remembered that too late. How about svn st -q .? That prints nothing if the folder is up to date. Did you meansvn st -u . ? How about the quicker (because non-recursively-scanning-the-whole-tree) svn info .? 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: filename with HASH
On 17/11/2011 00:29, pen wrote: Few more tests: seems lynx dont like # $ mv test bay#, wwid test # abc $ lynx -dump test # abc Can't Access `file://localhost/cygdrive/e/test%20#%20abc' Alert!: Unable to access document. lynx: Can't access startfile $ mv test # abc test# a $ lynx -dump test# a Looking up test Making HTTP connection to test Alert!: Unable to connect to remote host. lynx: Can't access startfile http://test/#%20a A # marks a separator in a URL between the URI part and the anchor within the page to load up the display at. I think lynx is applying the same syntax to local file URLs; for example, if you have a local file index.html, you can append any arbitrary # anchor to it: $ wget 'http://www.bbc.co.uk/' --2011-11-17 09:47:02-- http://www.bbc.co.uk/ Resolving www.bbc.co.uk (www.bbc.co.uk)... 212.58.246.94 Connecting to www.bbc.co.uk (www.bbc.co.uk)|212.58.246.94|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 135886 (133K) [text/html] Saving to: `index.html' 100%[==] 135,886 446K/s in 0.3s 2011-11-17 09:47:03 (446 KB/s) - `index.html' saved [135886/135886] $ ls index* index.html $ lynx -dump index.html#foobar #[1]A to Z [2]BBC Help [3]Terms of Use [4]British Broadcasting Corporation BBC Home [ ... snip ... ] So I think it's a limitation of the URL format that it's ambiguous between a filename with an actual # in it and a filename followed by # and an anchor, and there's probably not much lynx can do about it. Your best bet, if you absolutely have to use lynx on files with hash signs in their names, would be to use lynx's -stdin option and redirect the input from the file, so that lynx doesn't ever see the filename at all: $ lynx -dump index.html # abc Can't Access `file://localhost/tmp/lynx/index.html%20#%20abc' Alert!: Unable to access document. lynx: Can't access startfile $ lynx -stdin -dump index.html # abc #[1]A to Z [2]BBC Help [3]Terms of Use [4]British Broadcasting Corporation BBC Home [ ... snip ... ] 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: Problems with updating nearly any package meant for Cygwin or using packages such as libtool
On 17/11/2011 13:00, marco atzeri wrote: the problem is that the configure scripts incorrectly looks for libpcre.so that on cygwin is called differently: /usr/bin/cygpcre-0.dll so you need to modify the configure accordingly or remove the test and leave only the check for pcre.h same for libidn /usr/bin/cygidn-11.dll libpq /usr/bin/cygpq.dll and so on. These are upstream bugs in configure, looking for the lib is wrong as different platforms have different conventions. They should only look for the header. Well, they could look for the lib too, as long as they used the correct autoconf macro (AC_CHECK_LIB or AC_SEARCH_LIB) to do so. Rather than try searching in arbitrary and unknown places for unknown file names, that just tries running a compile with the relevant -l flag and seeing if it succeeds - which for the purposes of the build is more definitively accurate anyway. 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: Problems with updating nearly any package meant for Cygwin or using packages such as libtool
On 17/11/2011 20:33, Dave Korn wrote: On 17/11/2011 13:00, marco atzeri wrote: the problem is that the configure scripts incorrectly looks for libpcre.so that on cygwin is called differently: /usr/bin/cygpcre-0.dll so you need to modify the configure accordingly or remove the test and leave only the check for pcre.h same for libidn /usr/bin/cygidn-11.dll libpq /usr/bin/cygpq.dll and so on. These are upstream bugs in configure, looking for the lib is wrong as different platforms have different conventions. They should only look for the header. Well, they could look for the lib too, as long as they used the correct autoconf macro (AC_CHECK_LIB or AC_SEARCH_LIB) to do so. Whoops, no they can't. The hydra configure script isn't from autconf at all; it's just hand-written. Well, at least it serves as an object lesson in why you shouldn't do that (see also: reinventing the wheel, NIH syndrome). 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
[SOLVED] Re: What updates done after October 3 may affect gfortran built binaries?
On 09/11/2011 12:15, Edvardsen Kåre wrote: This is again related to the failure of execution of a gfortran built binary (cannot execute binary, see thread http://cygwin.com/ml/cygwin/2011-11/msg00034.html ) In short, the main problem is that I can't build a successful binary from the FLEXPART fortran code I helped Edvardsen to track this down off-list. It turns out that FLEXPART is one of those huge number-crunching Fortran programs that's just jam-packed with ginormous multi-dimensional arrays. The final linked executable had 3.38 GB of .bss space! So, it's not too surprising that it didn't load on 32-bit Windows; and it's not, as I was worrying, any explicit bug in the compiler or binutils (although it may be arguable that ld could be helpful if it issued some kind of warning in these circumstances). 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: [SOLVED] Re: What updates done after October 3 may affect gfortran built binaries?
On 15/11/2011 16:20, Ryan Johnson wrote: On 15/11/2011 10:53 AM, Dave Korn wrote: On 09/11/2011 12:15, Edvardsen Kåre wrote: In short, the main problem is that I can't build a successful binary from the FLEXPART fortran code FLEXPART is one of those huge number-crunching Fortran programs that's just jam-packed with ginormous multi-dimensional arrays. The final linked executable had 3.38 GB of .bss space! Out of curiosity, how then was the OP ever able to make *any* version run? Not clear yet but probably owing to changes in one or more of the array dimensions in the upstream source that he didn't notice taking place. 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: errors in setup --help
On 10/11/2011 16:14, Nellis, Kenneth wrote: Thought it may be worthwhile to point out the following setup.exe errors in case they indicate a problem that wants to be addressed. --Ken Nellis Thanks for mentioning it. They aren't significant, and it's only an inadvertent side-effect of the way that help output is routed to the console that they appear; they're not being printed out because they're relevant or important. The mentioned files are all optional files that are only created if you use the proxy or extra signing key features in setup.exe, so it's not a problem that they aren't found. 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
