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 2013-04-11 01:02, Dave Korn wrote: 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. Your boehm-gc patch can replace my java-libgc-win32.patch, provided it works properly. libitm needs some more work before enabling, at least on x86_64 due to weak symbol and sysv_abi assumptions (I have managed to get statically-linked executables to work, but not DLL-linked ones); on i686 it *might* actually work with just my patch (the one in 4.8 branch is better), but in the interest of time this should probably wait for a future release. Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies to 4.7 as well. 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. 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. 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. That was never right, CC isn't supposed to be (ab)used like that. I don't mind not supporting that going forward. 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. How could removing the .la files during postinstall affect building libjava beforehand? 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. 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. Should this be used on x86_64 as well? The libgcc/config.host hunk of your patch only mentions ix86. 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... Yaakov
[64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
Hi. I have tried to compile log4cplus (C++ logging library) on Cygwin64 with -flto GCC option. I am getting the following failure: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Here is a link (if Gmail does not botch it) to archive with the minimal amount of .o files and a test.sh script that reproduce the problem for me. https://docs.google.com/file/d/0B-WkLJEfYmSEUVVOdm56X1FSNDA/edit?usp=drive_web -- VZ
Re: GCC-4.7.2-2: Go/No-go?
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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: 64bit: cygstdc++-6.dll
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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: 64 bit: noarch packages and going beta
On Apr 10 23:28, Yaakov (Cygwin/X) wrote:
On 2013-04-10 08:16, Corinna Vinschen wrote:
- Does anybody know of a simple way to find out which packages in the 32
bit distro are actually noarch' packages? The reason I'm asking is
that I'm looking for a simple way to fill up the 64 bit distro with
all the packages which don't come with binaries, but consist entirely
of scripts and docs.
This should get us started:
for p in $(find release/ -name '*[0-9].tar.bz2');
do
if [ $(wc -c $p | cut -d' ' -f1) -gt 46 ] \
[ -f ${p%\.tar\.bz2}-src.tar.bz2 ] \
[ $(find ${p%/*} -name setup.hint | wc -l) -eq 1 ];
then
tar tf $p|grep -Eq '\.(exe|dll|so|a|cmxs|oct|dbg)' || echo ${p%/*};
fi;
done
Thanks!
However, I still think that separate i686/x86_64/noarch trees is the
way to go, otherwise those using both Cygwins will end up needlessly
downloading the same package twice, which doesn't happen on multilib
Linux distributions (even when there are two copies on the server).
We could just symlink the directories of noarch packages into the 64 bit
release. This would be a clear marker that the package doesn't contain
binaries.
Other than that, I'm still leaning towards an extra noarch directory,
too. It looks like the much cleaner approach.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
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
Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 4/11/2013 2:58 AM, Yaakov (Cygwin/X) wrote: 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. I know that cygwin-specific READMEs are now no longer required or expected in cygwin packages. However, I like to keep mine around to document things like packaging history, cygwin-specific user notes, build dependencies, and the like. I'll admit, tho, that avoiding the need to maintain setup.hints outside of the cygport(5) is nice, at least for simple package sets (that have only one binary tarball, plus the -src and the debuginfo). Three questions: #1) Is it possible to also record cygwin-specific README content within the cygport(5)? [1] If so, can you do more than one? (I'm thinking here of inetutils, which has a separate cygwin-specific README for the -server (sub)package and for the -client (sub)package). #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? #3) As I've been gone for a while, I might've missed recent changes: do setup.exe and/or cygport support build dependencies directly in any way, rather than the ad-hoc put-it-in-a-cygwin-README technique I've been using 'til now? [1] And I don't mean just putting a giant block of #-comment lines in the cygport(5). I mean ensuring that something gets intalled into /usr/share/doc/Cygwin/ with the appropriate name and all. -- Chuck
Re: 64bit: cygstdc++-6.dll
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? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
While the mirror script pulls down the shiny new gcc from Dave… Charles Wilson writes: #1) Is it possible to also record cygwin-specific README content within the cygport(5)? [1] If so, can you do more than one? (I'm thinking here of inetutils, which has a separate cygwin-specific README for the -server (sub)package and for the -client (sub)package). Here scripts (cat file EOF) would work, I've been using that to drop some few-line-long script in-place into the build once. I don't think it would necessarily work well for the README files, but I guess it's possible to append them to SRC_URI (you'd have to move them to the CYGWIN_PATCHES directory, though). If it's just the fact that editing a patch file is ugly, then you could do something along the lines of diff -u /dev/null package.README package.README.patch and then add package.README.patch to the PATCH_URI. But maybe Yaakov could consider something like README_URI instead (I think I could provide a patch to that effect). #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes, look at the recent packages for gmp/mpfr etc. #3) As I've been gone for a while, I might've missed recent changes: do setup.exe and/or cygport support build dependencies directly in any way, rather than the ad-hoc put-it-in-a-cygwin-README technique I've been using 'til now? I try to add both the requisite require lines to the *-devel package and a depend line in the cygport file. HTH, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[64bit] type conflict for INT32
/usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains typedef long INT32 Aside from the fact that this produces a confusing name for a 64-bit data type, it conflicts with /usr/include/w32api/basetsd.h, which has typedef signed int INT32 This causes a problem for the build of emacs-w32. Ken
Re: GCC-4.7.2-2: Go/No-go?
Am 11.04.2013 14:34, schrieb Dave Korn: On 11/04/2013 13:19, Corinna Vinschen 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.) ^^ If you really want to stick to an old gcc, make sure it's not the default. Call it gcc-3 or legacy-gcc, but let's get it out of the way of the most recent version. Yes, that's what I meant to imply by the wording. Different name + suffixed executables = out of the way. Also, I don't plan on doing it unless there's significant demand. I would appreciate to keep it as gcc-3. 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
(gcc-4.7.2-2 test) gmp / mpfr / mpclib / ppl / cloog-ppl
Test packages built with gcc-4.7.2-2, TLS is enabled and finally passing all tests for MPFR. I would appreciate if someone could check if the setup.hint files are correct before I send an RFU (or if I should omit them). If there's anything else I should change or check before RFU, please let me know. Questions: 1. Should ppl-doc be renamed libppl-doc? 2. Should documentation be split into libcloog-doc? # The first line sets up shell variable wget, to be used by all later lines # simply paste into the shell from here (assumes you are in .../release). --8---cut here---start-8--- wget=wget -rxnH --cut-dirs=1 http://cygwin.stromeko.net/release; $wget/gmp/setup.hint $wget/gmp/gmp-5.1.1-1.tar.bz2 $wget/gmp/gmp-5.1.1-1-src.tar.bz2 $wget/gmp/gmp-debuginfo/setup.hint $wget/gmp/gmp-debuginfo/gmp-debuginfo-5.1.1-1.tar.bz2 $wget/gmp/libgmp-doc/setup.hint $wget/gmp/libgmp-doc/libgmp-doc-5.1.1-1.tar.bz2 $wget/gmp/libgmp10/setup.hint $wget/gmp/libgmp10/libgmp10-5.1.1-1.tar.bz2 $wget/gmp/libgmpxx4/setup.hint $wget/gmp/libgmpxx4/libgmpxx4-5.1.1-1.tar.bz2 $wget/gmp/libgmp-devel/setup.hint $wget/gmp/libgmp-devel/libgmp-devel-5.1.1-1.tar.bz2 $wget/mpfr/setup.hint $wget/mpfr/mpfr-3.1.2-1.tar.bz2 $wget/mpfr/mpfr-3.1.2-1-src.tar.bz2 $wget/mpfr/mpfr-debuginfo/setup.hint $wget/mpfr/mpfr-debuginfo/mpfr-debuginfo-3.1.2-1.tar.bz2 $wget/mpfr/libmpfr-doc/setup.hint $wget/mpfr/libmpfr-doc/libmpfr-doc-3.1.2-1.tar.bz2 $wget/mpfr/libmpfr4/setup.hint $wget/mpfr/libmpfr4/libmpfr4-3.1.2-1.tar.bz2 $wget/mpfr/libmpfr-devel/setup.hint $wget/mpfr/libmpfr-devel/libmpfr-devel-3.1.2-1.tar.bz2 $wget/mpclib/setup.hint $wget/mpclib/mpclib-1.0.1-2.tar.bz2 $wget/mpclib/mpclib-1.0.1-2-src.tar.bz2 $wget/mpclib/mpclib-debuginfo/setup.hint $wget/mpclib/mpclib-debuginfo/mpclib-debuginfo-1.0.1-2.tar.bz2 $wget/mpclib/libmpc3/setup.hint $wget/mpclib/libmpc3/libmpc3-1.0.1-2.tar.bz2 $wget/mpclib/libmpc-doc/setup.hint $wget/mpclib/libmpc-doc/libmpc-doc-1.0.1-2.tar.bz2 $wget/mpclib/libmpc-devel/setup.hint $wget/mpclib/libmpc-devel/libmpc-devel-1.0.1-2.tar.bz2 $wget/ppl/setup.hint $wget/ppl/ppl-0.11.2-1.tar.bz2 $wget/ppl/ppl-0.11.2-1-src.tar.bz2 $wget/ppl/ppl-debuginfo/ppl-debuginfo-0.11.2-1.tar.bz2 $wget/ppl/ppl-debuginfo/setup.hint $wget/ppl/libppl9/setup.hint $wget/ppl/libppl9/libppl9-0.11.2-1.tar.bz2 $wget/ppl/libpwl5/setup.hint $wget/ppl/libpwl5/libpwl5-0.11.2-1.tar.bz2 $wget/ppl/libppl_c4/setup.hint $wget/ppl/libppl_c4/libppl_c4-0.11.2-1.tar.bz2 $wget/ppl/ppl-doc/setup.hint $wget/ppl/ppl-doc/ppl-doc-0.11.2-1.tar.bz2 $wget/ppl/libppl-devel/setup.hint $wget/ppl/libppl-devel/libppl-devel-0.11.2-1.tar.bz2 $wget/cloog-ppl/setup.hint $wget/cloog-ppl/cloog-ppl-0.15.11-1.tar.bz2 $wget/cloog-ppl/cloog-ppl-0.15.11-1-src.tar.bz2 $wget/cloog-ppl/cloog-ppl-debuginfo/setup.hint $wget/cloog-ppl/cloog-ppl-debuginfo/cloog-ppl-debuginfo-0.15.11-1.tar.bz2 $wget/cloog-ppl/libcloog0/setup.hint $wget/cloog-ppl/libcloog0/libcloog0-0.15.11-1.tar.bz2 $wget/cloog-ppl/libcloog-devel/libcloog-devel-0.15.11-1.tar.bz2 $wget/cloog-ppl/libcloog-devel/setup.hint --8---cut here---end---8--- Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [64bit] type conflict for INT32
On 2013-04-11 11:56, Ken Brown wrote: /usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains typedef long INT32 Aside from the fact that this produces a confusing name for a 64-bit data type Per the comment there: INT32 must hold *at least* signed 32-bit values (emphasis mine). it conflicts with /usr/include/w32api/basetsd.h, which has typedef signed int INT32 This causes a problem for the build of emacs-w32. Fortunately, the code doesn't seem to care about consistency in this type. Even on Linux, when itself is compiled for x86-64 this will be a 64-bit signed type, but when the header is used in conjunction with X11 headers (which have a typedef int INT32;), jmorecfg.h uses that and skips its own typedef. So it would seem we could do the same with w32api: === BEGIN === --- /usr/include/jmorecfg.h +++ /usr/include/jmorecfg.h @@ -161,4 +161,6 @@ #ifndef XMD_H /* X11/xmd.h correctly defines INT32 */ +#ifndef _BASETSD_H_/* w32api defines this in basetsd.h */ typedef long INT32; #endif +#endif === END === It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Yaakov
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 2013-04-11 07:37, Charles Wilson wrote: #1) Is it possible to also record cygwin-specific README content within the cygport(5)? [1] If so, can you do more than one? (I'm thinking here of inetutils, which has a separate cygwin-specific README for the -server (sub)package and for the -client (sub)package). No, cygport(1) doesn't generate README content. #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes; it just works, and also handles inter-subpackage dependencies (e.g. apps in foo will dep libfooX, and implibs in libfoo-devel will dep the corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION (there are also subpackage-specific variants of these) and omit the hint files from $C; at the end of the package stage, cygport will show you the dependencies it computes for each package so you can check them. If there are undetectable deps (e.g. commands called by a script or fork(), or runtime data, etc.), then those can be added in [$subpackage]_REQUIRES. #3) As I've been gone for a while, I might've missed recent changes: do setup.exe and/or cygport support build dependencies directly in any way, rather than the ad-hoc put-it-in-a-cygwin-README technique I've been using 'til now? See DEPEND in the cygport manual. (Yes, this is confusing now that REQUIRES exists for additional *runtime* dependencies. I'm thinking of renaming this to BUILDREQUIRES or the like, but for API compatibility DEPEND would still work.) These are checked at the beginning of the build step, and a warning issued if any are missing. Yaakov
Re: GCC-4.7.2-2: Go/No-go?
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.) 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. 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. 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? 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 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. Yaakov
Re: GCC-4.7.2-2: Go/No-go?
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? :-) Yaakov
Re: [64bit] type conflict for INT32
On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: On 2013-04-11 11:56, Ken Brown wrote: /usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains typedef long INT32 Aside from the fact that this produces a confusing name for a 64-bit data type Per the comment there: INT32 must hold *at least* signed 32-bit values (emphasis mine). it conflicts with /usr/include/w32api/basetsd.h, which has typedef signed int INT32 This causes a problem for the build of emacs-w32. Fortunately, the code doesn't seem to care about consistency in this type. Even on Linux, when itself is compiled for x86-64 this will be a 64-bit signed type, but when the header is used in conjunction with X11 headers (which have a typedef int INT32;), jmorecfg.h uses that and skips its own typedef. So it would seem we could do the same with w32api: === BEGIN === --- /usr/include/jmorecfg.h +++ /usr/include/jmorecfg.h @@ -161,4 +161,6 @@ #ifndef XMD_H/* X11/xmd.h correctly defines INT32 */ +#ifndef _BASETSD_H_/* w32api defines this in basetsd.h */ typedef long INT32; #endif +#endif === END === It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Yes, it works. Thanks. Ken
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
[ANNOUNCEMENT] Updated: xorg-server-1.14.0-2 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.0-2 These packages contain XWin and the other X.Org X11 servers. These packages are currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. Please try test releases and report problems to the Cygwin/X mailing list. Testing helps ensure good releases! The following cygwin-specific changes have been made since 1.14.0-1: * Various fixes for cygwin64 756e9047cb8f11ba6622e3304e127f27 *xorg-server-1.14.0-2.tar.bz2 32ff05ca5de01eb0abcfdda29a8c3225 *xorg-server-1.14.0-2-src.tar.bz2 dd2bde382f2c9e22f39d909cf3d12750 *xorg-server-common-1.14.0-2.tar.bz2 e08514cf5a733a5399665dc8694a308b *xorg-server-debuginfo-1.14.0-2.tar.bz2 3406ea25f64468e101196ab7419cab4a *xorg-server-devel-1.14.0-2.tar.bz2 b5408d9a353272931ab5a44028f692c6 *xorg-server-dmx-1.14.0-2.tar.bz2 73245bae07b4f4ad352ea5f5f92dc395 *xorg-server-extra-1.14.0-2.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Can't start X on MS Windows 7
I'm trying to run X under MS Windows 7 within Cygwin. I bring up a bash window, run startxwin I get: waiting for X server to begin accepting connections . .. .. .. .. and it never starts up. An X icon appears on the toolbar then disappears. XWin.exe shows up in the task manager doesn't exit. I searched the mailing list found the suggestion of wiping out the full installation reinstalling, but I'd rather avoid that. Any other ideas? Output (which appears to match /var/log/xwin/XWin.0.log): $ startxwin Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.14.0.0 OS: CYGWIN_NT-6.1-WOW64 NY731-3W-143A 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.14.0-2 built 2013-04-11 XWin was started with the following command line: X :0 -multiwindow Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension XFree86-Bigfont Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension X-Resource Initializing built-in extension GLX (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/hstein/.XWinrc not found LoadPreferences: Loading /etc/X11/system.XWinrc LoadPreferences: Done parsing the configuration file... winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD winDetectSupportedEngines - Windows NT, allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL winDetectSupportedEngines - Returning, supported engines 001f winSetEngine - Multi Window or Rootless = ShadowGDI winScreenInit - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 2560 height: 1440 depth: 32 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Calling pthread_mutex_lock () MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel GL_VERSION: 4.2.0 GL_VENDOR: NVIDIA Corporation GL_RENDERER:NVS 310/PCIe/SSE2 (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: enabled GLX_SGIX_pbuffer (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample (II) 482 pixel formats reported by wglGetPixelFormatAttribivARB (II) AIGLX: Set GLX version to 1.4 (II) 359 fbConfigs (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! winPointerWarpCursor - Discarding first warp: 1280 720 (--) 3 mouse buttons found waiting for X server to begin accepting connections . .. .. .. .. ..
src/winsup/cygwin ChangeLog child_info.h cyghe ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-04-11 12:13:01 Modified files: winsup/cygwin : ChangeLog child_info.h cygheap.cc cygheap.h cygtls.h cygwait.cc cygwait.h dcrt0.cc exceptions.cc sigproc.cc sigproc.h thread.cc thread.h Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.68r2=1.5939.2.69 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/child_info.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.92.2.8r2=1.92.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygheap.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.171.2.7r2=1.171.2.8 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygheap.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.161.2.8r2=1.161.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.80.2.18r2=1.80.2.19 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwait.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.7.2.1r2=1.7.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwait.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.7.2.2r2=1.7.2.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dcrt0.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.434.2.18r2=1.434.2.19 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.391.2.24r2=1.391.2.25 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.388.2.14r2=1.388.2.15 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.112.2.9r2=1.112.2.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.270.2.9r2=1.270.2.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.131.2.6r2=1.131.2.7
src/winsup/cygwin ChangeLog hires.h times.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2013-04-11 19:49:58 Modified files: winsup/cygwin : ChangeLog hires.h times.cc Log message: * hires.h (hires_ns::nsecs): Declare with bool parameter. * times.cc (hires_ns::nsecs): Take bool parameter. If set to true, don't use prime value (== return system wide absolute value). Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6090r2=1.6091 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/hires.h.diff?cvsroot=srcr1=1.21r2=1.22 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?cvsroot=srcr1=1.117r2=1.118
FIXED: GCC can't find its header directoriescy
Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Cheers ... Duncan. -- 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: 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: FIXED: GCC can't find its header directoriescy
Hi Duncan, On Thu, Apr 11, 2013 at 8:08 AM, Duncan Roe wrote: Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: FIXED: GCC can't find its header directoriescy
On Apr 11 09:49, Csaba Raduly wrote: Hi Duncan, On Thu, Apr 11, 2013 at 8:08 AM, Duncan Roe wrote: Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. And, just for kicks, moving the Cygwin DLL does not work as expected. The files under /etc are searched relative to the path of the Cygwin DLL, which is supposed to be in /bin. If it's not there, it will search the etc files in ..\\etc from it's new position. Confusion ensues. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please try the latest snapshot
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: The latest snapshot has some more signal-handling restructuring. I'd appreciate it if people would check it out. Looks good so far. I've had a compile that would pretty often lock up cmake during the config phase so that it needed to be killed from task manager. That seems to be gone, as well as the hangs that git would sometimes produce when doing lots of git-receive-pack back-to-back. Regards, Achim. -- 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
Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
Please CC your reply to fort...@gcc.gnu.org Dear all, using clock_gettime with CLOCK_MONOTONIC fails on Cygwin; it always gives 0. That breaks code compiled with GCC's gfortran which uses system_clock in libgfortran. libgfortran uses CLOCK_MONOTONIC if defined and otherwise it falls back to CLOCK_REALTIME (which works); however, Cygwin defines both. Maybe a better check would be _POSIX_MONOTONIC_CLOCK [2], however, that is also defined with Cygwin [1]. First, is a known problem that clock_gettime gives the wrong result? Secondly, do you have an idea how to test for it? One could use an exec test in configure, but that does not nicely work with cross compilations, which are commonly done for GCC. See http://gcc.gnu.org/ml/fortran/2013-04/msg00085.html for the thread at GCC, where the issue showed up. (The issue is new since GCC 4.6 (2011-01-31) as that's the first GCC version where libgfortran uses clock_gettime (when available); before gettimeofday was used. See also GCC bugreport 56919. And CLOCK_MONOTONIC appeared in Cygwin around the same time [Aug 2010], cf. [1]) Tobias [1] Cf. Cygwin-1.7.6 announcement at http://cygwin.com/ml/cygwin-announce/2010-08/msg00019.html and the #define _POSIX_MONOTONIC_CLOCK 200112L patch at http://sourceware.org/ml/newlib/2010/msg00454.html Note that Linux's glibc has in /usr/include/bits/posix_opt.h a more careful value: /* The monotonic clock might be available. */, #define _POSIX_MONOTONIC_CLOCK0 [2] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Apr 11 15:37, Tobias Burnus wrote:
Please CC your reply to fort...@gcc.gnu.org
Please don't CC me or cgf. We're subscribed to the Cygwin list anyway.
Dear all,
using clock_gettime with CLOCK_MONOTONIC fails on Cygwin; it always
gives 0. That breaks code compiled with GCC's gfortran which uses
system_clock in libgfortran.
Works fine for me with the current Cygwin 1.7.17, and the upcoming
Cygwin 1.7.18:
$ cat ct.c EOF
#include stdio.h
#include time.h
int
main ()
{
struct timespec tp;
sleep (1);
if (!clock_gettime (CLOCK_MONOTONIC, tp))
printf (tv_sec = %ld, tv_nsec = %ld\n, tp.tv_sec, tp.tv_nsec);
sleep (1);
if (!clock_gettime (CLOCK_MONOTONIC, tp))
printf (tv_sec = %ld, tv_nsec = %ld\n, tp.tv_sec, tp.tv_nsec);
sleep (1);
if (!clock_gettime (CLOCK_MONOTONIC, tp))
printf (tv_sec = %ld, tv_nsec = %ld\n, tp.tv_sec, tp.tv_nsec);
sleep (1);
if (!clock_gettime (CLOCK_MONOTONIC, tp))
printf (tv_sec = %ld, tv_nsec = %ld\n, tp.tv_sec, tp.tv_nsec);
}
EOF
$ gcc -o ct ct.c
$ ./ct
tv_sec = 0, tv_nsec = 29920
tv_sec = 1, tv_nsec = 15866090
tv_sec = 2, tv_nsec = 28048880
tv_sec = 3, tv_nsec = 42100530
$
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Server error 500 for snapshot list links?
Hi, When I try to list the contents of the snapshots using the List links on the right, I get an internal server error 500 for the recent ones. Fails: http://cygwin.com/snapshots/winsup-src-20130409.tar Works: http://cygwin.com/snapshots/winsup-src-20130309.tar Please fix / advise, Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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 Thu, Apr 11, 2013 at 01:43:24PM +0100, Dave Korn wrote: 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? I agree. Definitely 2 gold star worthy. -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
Hi mum [1], Corinna Vinschen wrote: Works fine for me with the current Cygwin 1.7.17, and the upcoming Cygwin 1.7.18: $ cat ct.c EOF At each run, your test case almost always starts with the same value: $ gcc -o ct ct.c $ ./ct tv_sec = 0, tv_nsec = 2793 tv_sec = 0, tv_nsec = 89104 tv_sec = 2, tv_nsec = 15365 tv_sec = 3, tv_nsec = 17879 $ ./ct tv_sec = 0, tv_nsec = 2793 tv_sec = 0, tv_nsec = 90222 tv_sec = 1, tv_nsec = 97765 tv_sec = 3, tv_nsec = 3911 $ ./ct tv_sec = 0, tv_nsec = 2793 tv_sec = 0, tv_nsec = 87428 tv_sec = 2, tv_nsec = 5587 tv_sec = 3, tv_nsec = 11453 $ ./ct tv_sec = 0, tv_nsec = 2793 tv_sec = 0, tv_nsec = 89942 tv_sec = 1, tv_nsec = 96088 tv_sec = 3, tv_nsec = 2514 $ ./ct tv_sec = 0, tv_nsec = 2793 tv_sec = 0, tv_nsec = 90222 tv_sec = 2, tv_nsec = 4190 tv_sec = 3, tv_nsec = 11733 $ ./ct tv_sec = 0, tv_nsec = 3073 tv_sec = 0, tv_nsec = 89942 tv_sec = 1, tv_nsec = 96926 tv_sec = 3, tv_nsec = 3911 [...] I wonder if this is to be expected... and, Tobias, why your test case [2] prints always 0 [3]? it looks very similar to that of Corinna.. oops mum.. ;-) Ciao, Angelo. --- [1] http://cygwin.com/ml/cygwin-apps/2013-04/msg00120.html [2] http://gcc.gnu.org/ml/fortran/2013-04/msg00082.html [3] http://gcc.gnu.org/ml/fortran/2013-04/msg00084.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
Corinna Vinschen wrote: Works fine for me with the current Cygwin 1.7.17, and the upcoming Cygwin 1.7.18: if (!clock_gettime (CLOCK_MONOTONIC, tp)) printf (tv_sec = %ld, tv_nsec = %ld\n, tp.tv_sec, tp.tv_nsec); ... tv_sec = 0, tv_nsec = 29920 Where is actually the source code of the clock_gettime, which Cygwin uses? I thought that it was newlib. But looking at http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/clock_gettime.c?cvsroot=src the code should return -1 for clock_gettime (CLOCK_MONOTONIC as CLOCK_MONOTONIC (= 4) is not handled, only CLOCK_REALTIME (= 1, according to src/newlib/libc/include/time.h). However, as both you and Angelo get a zero return value, I must look at the wrong file. Tobias -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin fstab odd behavior
Hi there, Using a combination of Cygwin 1.7.17 and Windows Server 2012. I put a samba share in the Cygwin /etc/fstab. I can log in as myself, and see the share/cd to it (I performed the cygwin install, and am a domain admin on the Windows machine). my issue arises when other users try to ssh into the Server 2012 machine. Their Cygwin environment shows that the mount exists, but as a file of eight exabytes in size, and not a directory that you can cd into. Here's my fstab: $ more /etc/fstab none /cygdrive cygdrive binary,posix=0,user 0 0,exec,noacl //hudson/sw /sw nfs nouser,noacl Here's what an ls of / look s like for most users: rwxr-xr-x+ 1 user user0 Jan 15 20:39 sbin drwxr-xr-x+ 1 user user0 Jan 15 21:23 srv -rw-r--r-- 1 jrm user user 9223655985735335684 Apr 22 2009 sw drwxrwxrwt+ 1 user user0 Apr 2 17:14 tmp Any idea as to what's going on? Thanks, -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Apr 11 21:09, Angelo Graziosi wrote: Hi mum [1], :) Corinna Vinschen wrote: Works fine for me with the current Cygwin 1.7.17, and the upcoming Cygwin 1.7.18: $ cat ct.c EOF At each run, your test case almost always starts with the same value: $ gcc -o ct ct.c [...] I wonder if this is to be expected... According to the Cygwin source code, yes. According to the SUSv4 definition, no. The timer used for the monotonic clock is inited to 0 for each process, so while each process uses the same clock, they all have their own monotonic value. This is obviously not how the monotonic system clock is supposed to work, so that's a bug in Cygwin. I fixed that in CVS. Mum -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Apr 11 21:13, Tobias Burnus wrote: Corinna Vinschen wrote: Works fine for me with the current Cygwin 1.7.17, and the upcoming Cygwin 1.7.18: if (!clock_gettime (CLOCK_MONOTONIC, tp)) printf (tv_sec = %ld, tv_nsec = %ld\n, tp.tv_sec, tp.tv_nsec); ... tv_sec = 0, tv_nsec = 29920 Where is actually the source code of the clock_gettime, which Cygwin uses? I thought that it was newlib. But looking at http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/clock_gettime.c?cvsroot=src the code should return -1 for clock_gettime (CLOCK_MONOTONIC as CLOCK_MONOTONIC (= 4) is not handled, only CLOCK_REALTIME (= 1, according to src/newlib/libc/include/time.h). However, as both you and Angelo get a zero return value, I must look at the wrong file. Yes, for Cygwin it's http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/timer.cc?cvsroot=src Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin fstab odd behavior
On Apr 11 15:17, Jeff Avila wrote: Hi there, Using a combination of Cygwin 1.7.17 and Windows Server 2012. I put a samba share in the Cygwin /etc/fstab. I can log in as myself, and see the share/cd to it (I performed the cygwin install, and am a domain admin on the Windows machine). my issue arises when other users try to ssh into the Server 2012 machine. Their Cygwin environment shows that the mount exists, but as a file of eight exabytes in size, and not a directory that you can cd into. Here's my fstab: $ more /etc/fstab none /cygdrive cygdrive binary,posix=0,user 0 0,exec,noacl //hudson/sw /sw nfs nouser,noacl Here's what an ls of / look s like for most users: rwxr-xr-x+ 1 user user0 Jan 15 20:39 sbin drwxr-xr-x+ 1 user user0 Jan 15 21:23 srv -rw-r--r-- 1 jrm user user 9223655985735335684 Apr 22 2009 sw drwxrwxrwt+ 1 user user0 Apr 2 17:14 tmp Any idea as to what's going on? Could you please generate an strace: $ strace -o ls.trace ls / and send it here? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cron Service Cannot Start: System error 1069 has occurred.
On 4/10/2013 4:47 AM, Jun Iriola wrote: Hi, I would like to seek your help on how to execute again the cron in my pc. I've manage to configure and run the cron last week by reading the step by step procedure and also by running cygwin as an Administrator. That's not what your cygcheck output reports. It says cron is running under 'cyg_server', which is the proper default. Also, you mention reading the step by step procedure. If that wasn't /usr/share/doc/Cygwin/cron-*.README, your method may very well be unsupported by this list. I would recommend starting over with the README file and cron-config. Then last weekend, I shutdown my desktop. Unfortunately, when I went to work today, I cannot manage to start the cron and this message appeared: System error 1069 has occurred.. I manage though to start the sshd service. $ net helpmsg 1069 The service did not start due to a logon failure. So the problem here is one of authentication, pointing back to initial configuration issues. But if you got the service started subsequently, I'm not sure I understand your inquiry here. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [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: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
Corinna Vinschen wrote: On Apr 11 21:13, Tobias Burnus wrote: Where is actually the source code of the clock_gettime, which Cygwin uses? I thought that it was newlib. But looking at http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/clock_gettime.c?cvsroot=src the code should return -1 for clock_gettime (CLOCK_MONOTONIC as CLOCK_MONOTONIC (= 4) is not handled, only CLOCK_REALTIME (= 1, according to src/newlib/libc/include/time.h). However, as both you and Angelo get a zero return value, I must look at the wrong file. Yes, for Cygwin it's http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/timer.cc?cvsroot=src Well, it's times.cc not timer.cc. I think the problem with Cygwin was a red herring. But there are a bunch of problems: a) Angelo's code to initialize the random seed assumes that Fortran's system_clock and the clock_gettime(CLOCK_MONOTONIC it calls give a result where 0 is the beginning of the epoch (like on Linux/glibc) or the system start up (as Windows' GetTickCount/GetTickCount64). However, QueryPerformanceCounter (probably intrinsically, but at least as used by Cygwin) returns some time based on the startup time - and as the frequency seems to be slow such that the result is 0 or (nearly) the same number for the startup. Thus, the random_seed initialization doesn't work as expected on Cygwin/Windows. b) Newlib is broken. For clock_gettime, CLOCK_MONOTONIC is not implemented. But both CLOCK_MONOTONIC and even _POSIX_MONOTONIC_CLOCK (with value 200112L) are defined. However, POSIX states: If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in time.h. Thus: * Newlib should be fixed to not define CLOCK_MONOTONIC and _POSIX_MONOTONIC_CLOCK - or it should implement it, otherwise it doesn't follow POSIX. * Angelo shouldn't use system_clock to set the random seed. * libgfortran should fall back to gf_gettime (= gettimeofday or clock_gettime CLOCK_REALTIME or time) if clock_gettime returns nonzero to work around the broken netlib (and possibly other implementations of clock_gettime) * gfortran's example for random_see should be change to not use system_clock for the random seed. Sorry for misinterpreting the results of Cygwin. And thanks for the reply and testing. Tobias -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Apr 11 22:35, Tobias Burnus wrote: Corinna Vinschen wrote: On Apr 11 21:13, Tobias Burnus wrote: Where is actually the source code of the clock_gettime, which Cygwin uses? I thought that it was newlib. But looking at http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/clock_gettime.c?cvsroot=src the code should return -1 for clock_gettime (CLOCK_MONOTONIC as CLOCK_MONOTONIC (= 4) is not handled, only CLOCK_REALTIME (= 1, according to src/newlib/libc/include/time.h). However, as both you and Angelo get a zero return value, I must look at the wrong file. Yes, for Cygwin it's http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/timer.cc?cvsroot=src Well, it's times.cc not timer.cc. I think the problem with Cygwin was a red herring. But there are a bunch of problems: a) Angelo's code to initialize the random seed assumes that Fortran's system_clock and the clock_gettime(CLOCK_MONOTONIC it calls give a result where 0 is the beginning of the epoch (like on Linux/glibc) or the system start up (as Windows' GetTickCount/GetTickCount64). However, QueryPerformanceCounter (probably intrinsically, but at least as used by Cygwin) returns some time based on the startup time http://cygwin.com/ml/cygwin/2013-04/msg00191.html - and as the frequency seems to be slow such that the result is 0 or (nearly) the same number for the startup. Thus, the random_seed initialization doesn't work as expected on Cygwin/Windows. b) Newlib is broken. For clock_gettime, CLOCK_MONOTONIC is not implemented. But both CLOCK_MONOTONIC and even _POSIX_MONOTONIC_CLOCK (with value 200112L) are defined. No, newlib is right. Look again. In libc/include/time.h CLOCK_MONOTONIC is only defined if _POSIX_MONOTONIC_CLOCK is defined. In libc/include/sys/features.h, _POSIX_MONOTONIC_CLOCK is only defined for RTEMS and Cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
Mum wrote: This is obviously not how the monotonic system clock is supposed to work, so that's a bug in Cygwin. I fixed that in CVS. Mum Oh, thanks mum... I hope it will be fixed also in the next 1.7.18.. :) Ciao, Angelo. PS. Corinna, your Hi kiddies has been irresistible... -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
Tobias Burnus: b) Newlib is broken. For clock_gettime, CLOCK_MONOTONIC is not implemented. But both CLOCK_MONOTONIC and even _POSIX_MONOTONIC_CLOCK (with value 200112L) are defined. However, POSIX states: If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in time.h. Sorry, I read this backward. CLOCK_MONOTONIC has to be in time.h according to POSIX [1]. However, whether the monotonic-clock option is supported, is given by _POSIX_MONOTONIC_CLOCK of unistd.h. POSIX states [2]: - If a symbolic constant is defined with the value -1, the option is not supported. - If a symbolic constant is defined with the value zero, all headers, data types, and functions shall be present. The application can check at runtime to see whether the option is supported. - If a symbolic constant is defined with a value greater than zero, the option shall always be supported when the application is executed. Just looking at newlib, the value should be -1; but a value of 0 is probably fine as well. For Cygwin it could also be 0. ... As Corinna has written as follow up, the latter is actually the case: Only RTEMS and Cygwin define it (with value 0). Regarding the zero value, the patch she mentions is: times.cc (hires_ns::nsecs): Take bool parameter. If set to true, don't use prime value (== return system wide absolute value)., http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?r1=1.117r2=1.118cvsroot=srcf=h Thanks for the patch! For libgfortran, as action item one should at least check whether _POSIX_MONOTONIC_CLOCK is defined as = 0 before assuming that monotonic clocks work. (With 0 (as with glibc/Linux) or with when not defined, it might be still available but according to POSIX that's only checkable via |sysconf(_SC_MONOTONIC_CLOCK|) at runtime.) Tobias [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html [2] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
On 4/11/2013 4:48 PM, Angelo Graziosi wrote: Mum wrote: This is obviously not how the monotonic system clock is supposed to work, so that's a bug in Cygwin. I fixed that in CVS. Mum Oh, thanks mum... I hope it will be fixed also in the next 1.7.18.. :) Yeah, that's pretty much the way these things work. Every release comes from what's in CVS. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fstab mounting fails for some cygwin users
Here go: 3 3 [main] ls (3892) ** 283 286 [main] ls (3892) Program name: C:\cygwin\bin\ls.exe (windows pid 3892) 130 416 [main] ls (3892) OS version: Windows NT-6.2 115 531 [main] ls (3892) ** 266 797 [main] ls (3892) sigprocmask: 0 = sigprocmask (0, 0x6123D468, 0x610FBA10) 4701267 [main] ls 3892 open_shared: name shared.5, n 5, shared 0x60FF (wanted 0x60FF), h 0x88, *m 6 1221389 [main] ls 3892 heap_init: heap base 0x8000, heap top 0x8000, heap size 0x1800 (402653184) 2121601 [main] ls 3892 open_shared: name S-1-5-21-786127098-345510345-965413785-1063.1, n 1, shared 0x60FE (wanted 0x60FE), h 0x80, *m 6 811682 [main] ls 3892 user_info::create: opening user shared for 'S-1-5-21-786127098-345510345-965413785-1063' at 0x60FE 831765 [main] ls 3892 user_info::create: user shared version 6467403B 1201885 [main] ls 3892 fhandler_pipe::create: name \\.\pipe\cygwin-c5e39b7a9d22bafb-3892-sigwait, size 164, mode PIPE_TYPE_MESSAGE 1292014 [main] ls 3892 fhandler_pipe::create: pipe read handle 0x9C 582072 [main] ls 3892 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c5e39b7a9d22bafb-3892-sigwait 1112183 [main] ls 3892 fhandler_pipe::create: pipe write handle 0xA0 662249 [main] ls 3892 dll_crt0_0: finished dll_crt0_0 initialization 8265 10514 [main] ls 3892 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home, no-keep-rel, no-add-slash) 108 10622 [main] ls 3892 normalize_win32_path: C:\cygwin\home = normalize_win32_path (C:\cygwin\home) 63 10685 [main] ls 3892 mount_info::conv_to_posix_path: /home = conv_to_posix_path (C:\cygwin\home) 113 10798 [main] ls 3892 sigprocmask: 0 = sigprocmask (0, 0x800180A8, 0x610FBA10) 305 11103 [main] ls 3892 _cygwin_istext_for_stdio: fd 0: not open 58 11161 [main] ls 3892 _cygwin_istext_for_stdio: fd 1: not open -159 11002 [sig] ls 3892 wait_sig: entering ReadFile loop, my_readsig 0x9C, my_sendsig 0xA0 211 11213 [main] ls 3892 _cygwin_istext_for_stdio: fd 2: not open 273 11486 [main] ls (3892) open_shared: name cygpid.3892, n 3892, shared 0x60FD (wanted 0x60FD), h 0x128, *m 2 108 11594 [main] ls 3892 pinfo::thisproc: myself dwProcessId 3892 56 11650 [main] ls 3892 time: 1365710327 = time(0) 708 12358 [main] ls 3892 environ_init: GetEnvironmentStrings returned 0x4E7298 98 12456 [main] ls 3892 environ_init: 0x80028290: _=/usr/bin/strace 92 12548 [main] ls 3892 environ_init: 0x800282A8: !C:=C:\cygwin\home 94 12642 [main] ls 3892 environ_init: 0x800282C0: ALLUSERSPROFILE=C:\ProgramData 95 12737 [main] ls 3892 environ_init: 0x800282E8: APPDATA=C:\Users\jrm\AppData\Roaming 97 12834 [main] ls 3892 environ_init: 0x80028318: COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files 99 12933 [main] ls 3892 environ_init: 0x80028358: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 97 13030 [main] ls 3892 environ_init: 0x800283A0: CommonProgramW6432=C:\Program Files\Common Files 94 13124 [main] ls 3892 environ_init: 0x800283D8: COMPUTERNAME=MELROSE 96 13220 [main] ls 3892 environ_init: 0x800283F8: COMSPEC=C:\Windows\system32\cmd.exe 102 13322 [main] ls 3892 parse_options: glob (called func) 92 13414 [main] ls 3892 parse_options: returning 50 13464 [main] ls 3892 environ_init: 0x80028428: CYGWIN=noglob 93 13557 [main] ls 3892 environ_init: 0x80028450: EXA_SH_LOGINVARS_SET=sh-jrm 100 13657 [main] ls 3892 environ_init: 0x80028478: EXACORP_LICENSE=5053@boltzmann 183 13840 [main] ls 3892 environ_init: 0x800284A0: FP_NO_HOST_CHECK=NO 188 14028 [main] ls 3892 getwinenv: can't set native for HOME= since no environ yet 137 14165 [main] ls 3892 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home, no-keep-rel, no-add-slash) 133 14298 [main] ls 3892 normalize_win32_path: C:\cygwin\home = normalize_win32_path (C:\cygwin\home) 73 14371 [main] ls 3892 mount_info::conv_to_posix_path: /home = conv_to_posix_path (C:\cygwin\home) 349 14720 [main] ls 3892 win_env::add_cache: posix /home 99 14819 [main] ls 3892 win_env::add_cache: native HOME=C:\cygwin\home 68 14887 [main] ls 3892 posify_maybe: env var converted to HOME=/home 205 15092 [main] ls 3892 environ_init: 0x80028508: HOME=/home 184 15276 [main] ls 3892 environ_init: 0x800284C0: HOMEDRIVE=C: 142 15418 [main] ls 3892 environ_init: 0x80028518: HOMEPATH=\Users\jrm 182 15600 [main] ls 3892 environ_init: 0x80028538: HOST=MELROSE 136 15736 [main] ls 3892 environ_init: 0x80028550: HOSTNAME=MELROSE 131 15867 [main] ls 3892 environ_init: 0x80028568: INFOPATH=/usr/local/info:/usr/share/info:/usr/info: 99 15966 [main] ls 3892 environ_init: 0x800285A8: LANG=en_US.UTF-8 93 16059 [main] ls 3892 environ_init: 0x800285C0:
UDP/DTLS sockets communication pattern is broken in Cygwin
Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. Thanks! Oleg Moskalenko -- 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: UDP/DTLS sockets communication pattern is broken in Cygwin
On Thu, Apr 11, 2013 at 02:19:25PM -0700, Oleg Moskalenko wrote: Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. How about a simple test case? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: UDP/DTLS sockets communication pattern is broken in Cygwin
I can write a simple test server and client programs and I'll post it here,= in a few hours. Our existing code is just too large. Thanks Oleg On Thu, Apr 11, 2013 at 02:19:25PM -0700, Oleg Moskalenko wrote: Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. How about a simple test case? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Thu, Apr 11, 2013 at 10:35:54PM +0200, Tobias Burnus wrote: * gfortran's example for random_see should be change to not use system_clock for the random seed. I disagree. The example is just that a short example that demonstrates how to use random_seed. Anyone using that example in his/her code without testing the results in his/her potentially broken environment should not be programming. -- Steve -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Apr 11 2013, Steve Kargl wrote: On Thu, Apr 11, 2013 at 10:35:54PM +0200, Tobias Burnus wrote: * gfortran's example for random_see should be change to not use system_clock for the random seed. I disagree. The example is just that a short example that demonstrates how to use random_seed. Anyone using that example in his/her code without testing the results in his/her potentially broken environment should not be programming. That is unfair. Few scientists will know that system clocks are an iffy aspect of a programming language, especially as there are no fundamental reasons that should be the case. People who have been around for a while will know that, and I can witness that they have been made a complete mess of since the 1960s, quite often preserving the defects of ancient designs in new designs that have no functional aspect in common. But why on earth should any sane person expect that? Regards, Nick Maclaren. -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Thu, Apr 11, 2013 at 11:23:42PM +0100, N.M. Maclaren wrote: On Apr 11 2013, Steve Kargl wrote: On Thu, Apr 11, 2013 at 10:35:54PM +0200, Tobias Burnus wrote: * gfortran's example for random_see should be change to not use system_clock for the random seed. I disagree. The example is just that a short example that demonstrates how to use random_seed. Anyone using that example in his/her code without testing the results in his/her potentially broken environment should not be programming. That is unfair. Few scientists will know that system clocks are an iffy aspect of a programming language, especially as there are no fundamental reasons that should be the case. This has nothing to do with the iffy-ness of system clocks. My disagreemnet is predicated on the stupidity of using a 10 line example subroutine without actually inspecting what it does on whatever OS that one chooses to use. Perhaps, my expectations for the IQ of scientists is too high. Are you suggesting that every code snippet in the manual should contain a cautionary comment of the form: ! ! This is only an example. Use with extreme caution. ! -- Steve -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
Steve Kargl wrote: On Thu, Apr 11, 2013 at 10:35:54PM +0200, Tobias Burnus wrote: * gfortran's example for random_see should be change to not use system_clock for the random seed. I disagree. The example is just that a short example that demonstrates how to use random_seed. Anyone using that example in his/her code without testing the results in his/her potentially broken environment should not be programming. Obviously I test the code before using it, and it worked fine since oct. 2010 on different systems: Fedora, Ubuntu, Kubuntu and also on Cygwin (as long as one uses GCC-4.5). It is only recently, with GCC = 4.7, I noticed the problems on Cygwin. BTW, I changed the method to initialize the random seed more than a month ago. Ciao, Angelo. -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On 11/04/2013 7:00 PM, Steve Kargl wrote: On Thu, Apr 11, 2013 at 11:23:42PM +0100, N.M. Maclaren wrote: On Apr 11 2013, Steve Kargl wrote: On Thu, Apr 11, 2013 at 10:35:54PM +0200, Tobias Burnus wrote: * gfortran's example for random_see should be change to not use system_clock for the random seed. I disagree. The example is just that a short example that demonstrates how to use random_seed. Anyone using that example in his/her code without testing the results in his/her potentially broken environment should not be programming. That is unfair. Few scientists will know that system clocks are an iffy aspect of a programming language, especially as there are no fundamental reasons that should be the case. This has nothing to do with the iffy-ness of system clocks. My disagreemnet is predicated on the stupidity of using a 10 line example subroutine without actually inspecting what it does on whatever OS that one chooses to use. Perhaps, my expectations for the IQ of scientists is too high. Are you suggesting that every code snippet in the manual should contain a cautionary comment of the form: ! ! This is only an example. Use with extreme caution. ! This has wandered off topic into some pretty snitty territory... truce? -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
Steve Kargl wrote My disagreemnet is predicated on the stupidity of using a 10 line example subroutine without actually inspecting what it does on whatever OS that one chooses to use. It is just because one has tested that code that these problems came to light... :-) Ciao, Angelo. -- 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 with clock_gettime and CLOCK_MONOTONIC - gives always 0
On Fri, Apr 12, 2013 at 01:17:07AM +0200, Angelo Graziosi wrote: Steve Kargl wrote My disagreemnet is predicated on the stupidity of using a 10 line example subroutine without actually inspecting what it does on whatever OS that one chooses to use. It is just because one has tested that code that these problems came to light... :-) When testing, it would help if the results were properly represented as your initial subject line was Random seed initialization. It seems clear to at least me your testing did not include actually inspecting what these two lines do: CALL SYSTEM_CLOCK(COUNT=clock) seed = clock + 37 * (/ (i-1), 1=1, n) /) because your subject would have been SYSTEM_CLOCK is broken on cygwin. If you want to see an actual issue with Random seed initialization go read PR 52879. -- Steve -- 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: FIXED: GCC can't find its header directoriescy
Hi Casba, On Thu, Apr 11, 2013 at 8:08 AM, Duncan Roe wrote: Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. Csaba OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? Cheers ... Duncan. -- 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: UDP/DTLS sockets communication pattern is broken in Cygwin
I am sending the test case in the attachment. In the attachment, you will find source code for two programs - udpbugserver and udpbugclient. make will build them both. They work perfectly together in Linux, FreeBSD and Solaris. But they fail in Cygwin. Thanks Oleg On Thu, Apr 11, 2013 at 02:19:25PM -0700, Oleg Moskalenko wrote: Hi All I found a non-standard behavior of UDP sockets in Cygwin. Normally, people = do not experience it, but the communication pattern that I am going to desc= ribe here is often used in DTLS (actually, this is virtually the only way t= o make OpenSSL working with DTLS on the server side), so I suppose that wit= h the growing DTLS popularity people will experience the problem often. So this is how to reproduce the problem in plain UDP (without actually using DTLS): 1) Server application: open a UDP socket (socket A); 2) Server application: bind socket A to a local server address (say, 172.17.17.107:3478); 3) Server application: wait for a packet from a client application; 4) Client application: open a UDP socket (socket C); 5) Client application: bind socket C it to a local client address (say, 168.16.16.106:12345); 6) Client application: send a UDP packet P1 from socket C to server socket A (to 172.17.17.107:3478); 7) Server application: socket A receives the packet P1 from socket C; 8) Server application: create another UDP socket B; 9) Server application: bind socket B TO THE SAME LOCAL ADDRESS as socket A (172.17.17.107:3478); 10) Server application: connect socket B to the remote address of socket C (168.16.16.106:12345) by calling connect() on the datagram socket B. 11) Server application: send packet P2 from socket B to socket C (to 168.16.16.106:12345). 12) Client application: on socket C, receive packet P2 from socket B (from 172.17.17.107:3478). 13) Client application: from socket C, send packet P3 to the server address 172.17.17.107:3478. 14) Server application: socket A receives the packet P3 from the client socket. ERROR !!! Step 14 is wrong: the packet P3 must be delivered to socket B, because socket B is connected to the remote address 168.16.16.106:12345, but socket A is unconnected. Both sockets (A and B) are bound to the same server ad= dress (172.17.17.107:3478) but the connected one (socket B) must be obtaining packets from the remote address that it is connected to. This is a very essential functionality for anybody who wants to implement the server-side DTLS communications. This patterns works in any OS that I tried (all FreeBSD versions, all Linux versions and Solaris) but Cygwin fails, unfortunately. I am trying to migrate (port) our server application to Cygwin, and it stops us completely. It works everywhere else. Please take a look if this is something that can be fixed quickly. How about a simple test case? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple cygwinbug.tar.gz Description: cygwinbug.tar.gz -- 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: FIXED: GCC can't find its header directoriescy
On 4/11/2013 8:05 PM, Duncan Roe wrote: Hi Casba, On Thu, Apr 11, 2013 at 8:08 AM, Duncan Roe wrote: Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. Csaba OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? If you always want Cygwin to be available, just set it in your environment with the rest of your settings. Run systemPropertiesAdvanced.exe, click the Environment Variables... button, and either append to the PATH variable in System variables (if you want everyone to see Cygwin) or add PATH to your user environment variables. -- Larry -- 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: FIXED: GCC can't find its header directoriescy
On 4/11/2013 10:27 PM, Larry Hall (Cygwin Developers) wrote: On 4/11/2013 8:05 PM, Duncan Roe wrote: Hi Casba, On Thu, Apr 11, 2013 at 8:08 AM, Duncan Roe wrote: Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. Csaba OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? If you always want Cygwin to be available, just set it in your environment with the rest of your settings. Run systemPropertiesAdvanced.exe, click the Environment Variables... button, and either append to the PATH variable in System variables (if you want everyone to see Cygwin) or add PATH to your user environment variables. Apologies everyone. If you want to follow-up on my previous post, please reply to this one instead so that the response goes to this list instead of Cygwin-Developers. Thanks, -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin with clock_gettime and CLOCK_MONOTONIC - gives always 0
Greetings, Steve Kargl! * gfortran's example for random_see should be change to not use system_clock for the random seed. I disagree. The example is just that a short example that demonstrates how to use random_seed. Anyone using that example in his/her code without testing the results in his/her potentially broken environment should not be programming. That is unfair. Few scientists will know that system clocks are an iffy aspect of a programming language, especially as there are no fundamental reasons that should be the case. This has nothing to do with the iffy-ness of system clocks. My disagreemnet is predicated on the stupidity of using a 10 line example subroutine without actually inspecting what it does on whatever OS that one chooses to use. Perhaps, my expectations for the IQ of scientists is too high. Are you suggesting that every code snippet in the manual should contain a cautionary comment of the form: No, I expect a code snippet in manual to produce sensible, reliable and predictable results across the board, especially for such generic cases. ! ! This is only an example. Use with extreme caution. ! -- WBR, Andrey Repin (anrdae...@freemail.ru) 12.04.2013, 06:29 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FIXED: GCC can't find its header directoriescy
Greetings, Duncan Roe! Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. Csaba OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? Whatever drives your car. Usually, it is My computer properties - Advanced - Environment Adjust either system or user environment settings. -- WBR, Andrey Repin (anrdae...@freemail.ru) 12.04.2013, 06:27 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: FIXED: GCC can't find its header directoriescy
Thanks all - it is done Greetings, Duncan Roe! Thanks Dave - removing the old cygwin dlls from C:\WINDOWS fixed gcc alternatives. 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, Adding c:\cygwn\bin to the Windows PATH might be a better solution; that's what I did. Csaba OK I'm convinced. But ... how do I do it? Registry? autoexec.bat? other? Whatever drives your car. Usually, it is My computer properties - Advanced - Environment Adjust either system or user environment settings. WBR, Andrey Repin 12.04.2013, 06:27 That worked for me. Many thanks, Cheers ... Duncan. -- 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 64bit] automake 1.13.1-1: Fix config.guess result
Recent config.guess still detects 64bit Cygwin as x86_64-unknown-cygwin.
This should probably be changed (upstream) to be consistent with
i686-pc-cygwin.
$ uname -srvmo
CYGWIN_NT-6.1 1.7.18(0.263/5/3) 2013-04-10 14:35 x86_64 Cygwin
$ cygcheck -f /usr/share/automake-1.13/config.guess
automake1.13-1.13.1-1
$ /usr/share/automake-1.13/config.guess
x86_64-unknown-cygwin
Christian
--- config.guess.orig 2013-03-11 01:18:17.0 +0100
+++ config.guess 2013-04-12 07:19:56.583395800 +0200
@@ -847,7 +847,7 @@
echo ${UNAME_MACHINE}-pc-uwin
exit ;;
amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
- echo x86_64-unknown-cygwin
+ echo x86_64-pc-cygwin
exit ;;
p*:CYGWIN*:*)
echo powerpcle-unknown-cygwin
--
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
