Re: GCC-4.7.2-2: Go/No-go?
On Apr 9 17:17, Dave Korn wrote: Hi all, I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs work and restores java and libffi. I've also been running the testsuite over the last few days and the results look quite reasonable. Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that I shouldn't release it until I've integrated all his patches. I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's worth uploading as a stop-gap to address the mentioned problems and integrating Yaakov's patches for the next release. Could the list please help us make a decision? I'd prefer if we could get 4.7.2 into the distro rather sooner than later. As long as it is a test release, it doesn't matter much if all patches are in. For the first real release it would be better to have them, if they are necessary, though. How far away are we from there? And while we're at it, what about reviewing Achim's gmp/mpfr/mpclib/ ppl/cloog-ppl packages? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [ITP] hostname 3.12 (Attn: coreutils maintainer)
On Apr 9 22:55, Christian Franke wrote: I would like to contribute the (Debian) Linux version of hostname(1) and would suggest to remove the GNU hostname command from coreutils package. This version of hostname allows to show the FQDN (-f), DNS domain name (-d, dnsdomainname), alias names (-a, -A) or network addresses (-i, -I). Works reasonably on Cygwin. It is a slightly patched version of hostname 3.12 from Debian unstable which is at least also used on Fedora. http://packages.debian.org/unstable/hostname The packages below are intended for testing. Command and man page are installed as hostname-linux with the usual symlinks domainname and dnsdomainname. This should keep hostname from coreutils intact. [...] I'm just generating a 64 bit coreutils package without hostname. If you provide a new 64 bit package with hostname being called hostname, I could upload them together later today. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[RFC] libjpeg-turbo
Chuck (and other affected parties), The libjpeg-turbo project provides SIMD acceleration while remaining API and ABI compatible with IJG libjpeg 6b/7/8 (based on configure flags). I have been using this libjpeg8 locally instead of the IJG one from the distro for some time, and have seen no ABI incompatibilities. Fedora switched from IJG libjpeg to libjpeg-turbo in F14, and did the same in their MinGW toolchain for F16 (when they switched from mingw.org to mingw-w64). Perhaps we should do the same? http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libjpeg-turbo -- Yaakov
[ITP] libffi (attn: Dave Korn)
libffi development moved out of GCC into a separate project a long time ago; the copy included in GCC is used for libgcj, but only as a convenience (static) library, and it is usually a few point releases behind the standalone version. Finally, last month, GCC was patched upstream to stop installing its copy (a similar patch for 4.7.2 and 4.8.0 is in Ports git). Therefore I think the time has arrived to join Fedora and Debian and switch i686 to the standalone version. (We are already using this for x86_64.) This will also simplify building many of the ~20 packages which use libffi and expect the .pc file provided only by the standalone version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/ Yaakov
Re: [ITP] libffi (attn: Dave Korn)
On Apr 10 04:06, Yaakov (Cygwin/X) wrote: libffi development moved out of GCC into a separate project a long time ago; the copy included in GCC is used for libgcj, but only as a convenience (static) library, and it is usually a few point releases behind the standalone version. Finally, last month, GCC was patched upstream to stop installing its copy (a similar patch for 4.7.2 and 4.8.0 is in Ports git). Therefore I think the time has arrived to join Fedora and Debian and switch i686 to the standalone version. (We are already using this for x86_64.) This will also simplify building many of the ~20 packages which use libffi and expect the .pc file provided only by the standalone version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/ Isn't that independent from what gcc itself does? If so, feel free to upload. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [ITP] hostname 3.12 (Attn: coreutils maintainer)
On Apr 10 09:57, Corinna Vinschen wrote: On Apr 9 22:55, Christian Franke wrote: I would like to contribute the (Debian) Linux version of hostname(1) and would suggest to remove the GNU hostname command from coreutils package. This version of hostname allows to show the FQDN (-f), DNS domain name (-d, dnsdomainname), alias names (-a, -A) or network addresses (-i, -I). Works reasonably on Cygwin. It is a slightly patched version of hostname 3.12 from Debian unstable which is at least also used on Fedora. http://packages.debian.org/unstable/hostname The packages below are intended for testing. Command and man page are installed as hostname-linux with the usual symlinks domainname and dnsdomainname. This should keep hostname from coreutils intact. [...] I'm just generating a 64 bit coreutils package without hostname. If you provide a new 64 bit package with hostname being called hostname, I could upload them together later today. Just FYI, the hostnameless coreutils package is ready for upload. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [ITA] gmp (libgmp-devel / libgmp3 / libgmpxx4)
On 2013-04-02 10:26, Achim Gratz wrote: I've added test packages compiled with gcc-4.7.2-1 (to be installed by manually selecting them, like the test version of gcc itself): Style point: doins can take multiple arguments at once, and for installing docs, use docinto/dodoc instead, e.g.: docinto html dodoc path/to/docs/* GTG. Yaakov
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 2013-04-02 10:27, Achim Gratz wrote:
I've added test packages compiled with gcc-4.7.2-1 (to be installed by
manually selecting them, like the test version of gcc itself):
FYI, 3.1.2 is out now.
Also, automating the patches is possible, e.g.:
PATCH_URI=$(seq -f http://www.mpfr.org/mpfr-${VERSION}/patch%02.0f 1 3)
Then use the '3' to control the number of patches available.
Use docinto/dodoc as in GMP.
GTG.
Yaakov
Re: [ITA] mpclib (mpclib-devel / libmpc1 / libmpc3)
On 2013-04-02 10:27, Achim Gratz wrote: I've added test packages compiled with gcc-4.7.2-1 (to be installed by manually selecting them, like the test version of gcc itself): PKG_CONTENTS[] is deprecated. Instead, do: mpclib_CONTENTS='usr/share' libmpc3_CONTENTS='usr/bin/cygmpc-3.dll' libmpc_devel_CONTENTS='usr/include/ usr/lib/' Same story for docinto/dodoc. GTG. Yaakov
Re: [ITP] libffi (attn: Dave Korn)
On 2013-04-10 04:29, Corinna Vinschen wrote: On Apr 10 04:06, Yaakov (Cygwin/X) wrote: libffi development moved out of GCC into a separate project a long time ago; the copy included in GCC is used for libgcj, but only as a convenience (static) library, and it is usually a few point releases behind the standalone version. Finally, last month, GCC was patched upstream to stop installing its copy (a similar patch for 4.7.2 and 4.8.0 is in Ports git). Therefore I think the time has arrived to join Fedora and Debian and switch i686 to the standalone version. (We are already using this for x86_64.) This will also simplify building many of the ~20 packages which use libffi and expect the .pc file provided only by the standalone version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/ Isn't that independent from what gcc itself does? If so, feel free to upload. Only the man3 pages collide with gcc4-core. But gcc's libffi.dll.a will take priority over the one in /usr/lib (see gcc -print-search-dirs), so manual intervention will be necessary until our gcc stops shipping libffi. Yaakov
Re: 64bit: cygstdc++-6.dll
On 2013-04-09 11:11, Dave Korn wrote: On 09/04/2013 11:30, Yaakov (Cygwin/X) wrote: On 2013-04-09 02:08, Dave Korn wrote: On 25/03/2013 08:52, Corinna Vinschen wrote: On Mar 24 03:33, Yaakov (Cygwin/X) wrote: In any case, the error is a result of adding one of Dave Korn's patches: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29 I have omitted that patch in the new 4.8.0-1. Hopefully Dave can explain the purpose and necessity of that patch, since it would seem that using (at least that hunk of) it would require rebuilding most C++ packages in 64bit/release; if it's really necessary, then we will want to do that sooner rather than later. I believe the patch is no longer necessary. Does that apply to the entire dllimport patch or just that hunk? Just the hunk with the --exclude-modules-for-implib. Thanks for the clarification; I have removed this from my patchset. Could you explain the necessity of the dllimport's in the same patch? Yaakov
Re: [ITA] ppl / cloog-ppl
On 2013-04-06 05:45, Achim Gratz wrote: Packages orphaned by David Billinghurst. Test version for gcc-4.7.2 only. GTG. When installing, make sure you de-install all old packages to avoid old files sticking around due to the package renames. We can create obsolete packages to handle the renames; just remind me in the RFU. Yaakov
Re: [SECURITY] tiff
On 2012-12-15 23:06, Yaakov (Cygwin/X) wrote: Chuck, Security vulnerabilities have been announced for the tiff package. Please update tiff to 3.9.7 together with this patchset ASAP: http://pkgs.fedoraproject.org/cgit/libtiff.git/tree/?h=f17 http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/tiff Yaakov
Re: [RFC] libjpeg-turbo
On 4/10/2013 4:03 AM, Yaakov (Cygwin/X) wrote: The libjpeg-turbo project provides SIMD acceleration while remaining API and ABI compatible with IJG libjpeg 6b/7/8 (based on configure flags). I have been using this libjpeg8 locally instead of the IJG one from the distro for some time, and have seen no ABI incompatibilities. Fedora switched from IJG libjpeg to libjpeg-turbo in F14, and did the same in their MinGW toolchain for F16 (when they switched from mingw.org to mingw-w64). Perhaps we should do the same? Yes, I've been considering switching for some time (especially given the...mess...that IJG libjpeg development has been for the past few years.) I'm willing, unless there's strong objection from the list. BTW, which processor do we target these days in 32bit cygwin, as that will affect which SIMD instruction set is enabled whn libjpeg-turbo is built? i686? -- Chuck
Re: [RFC] libjpeg-turbo
On 2013-04-10 06:49, Charles Wilson wrote: BTW, which processor do we target these days in 32bit cygwin, as that will affect which SIMD instruction set is enabled whn libjpeg-turbo is built? i686? i686-pc-cygwin-gcc is configured with --with-arch=i686 --with-tune=generic. Yaakov
64 bit Cygwin 1.7.18-18
Hi kiddies, I just uploaded the 64 bit cygwin 1.7.18-18 package. About 4 weeks ago I ripped out ptmalloc3. The reason was ptmalloc3 always used mmap. Duplicating many mmaps at fork time is noticably less performant than duplicating the heap, so I thought ptmalloc3 is not useful for us. However, I investigated this again today, and it turned out that my assumption was based on some default settings, which I didn't quite understood at the time (dlmalloc has lots of intertwined settings). I now reinstantiated ptmalloc3 in the 64 bit branch again, this time with a tweak which lets ptmalloc3 prefer heap memory over mmap'ed memory. It seems to work nicely, at least a complete configure/make of lynx worked as designed. Ultimately we might switch to jemalloc(*) at one point, but for the time being, ptmalloc3 seems to be a nice compromise, given how much faster it is in a multi-threaded environment. So, please test. If you see that anything is reproducibly broken, just by updating from 1.7.18-17 to 1.7.18-18, please report it here. Thanks, Corinna (*) http://www.canonware.com/jemalloc/ -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
64 bit: noarch packages and going beta
Greetings venerable maintainers, I have two questions: - 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. - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? Thanks for your input, 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 4/10/2013 9:16 AM, Corinna Vinschen wrote: Greetings venerable maintainers, I have two questions: - 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. - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? I've been finding it quite stable. Opening it up to a wider audience seems like a good idea. Ken
Re: 64 bit: noarch packages and going beta
On Wed, Apr 10, 2013 at 3:16 AM, Corinna Vinschen wrote: Greetings venerable maintainers, I have two questions: - 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. - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? Might not be a bad idea to get the gcc testsuite to pass. It's huge, and thus somewhat comprehensive. Maybe there's some other packages out there with giant testsuites, too.
Re: 64 bit: noarch packages and going beta
On Apr 10 03:38, NightStrike wrote: On Wed, Apr 10, 2013 at 3:16 AM, Corinna Vinschen wrote: Greetings venerable maintainers, I have two questions: - 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. - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? Might not be a bad idea to get the gcc testsuite to pass. It's huge, and thus somewhat comprehensive. Maybe there's some other packages out there with giant testsuites, too. Not exactly giant testsuites, but openssh, gawk and sed testsuites passed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
Yaakov (Cygwin/X) writes:
On 2013-04-02 10:27, Achim Gratz wrote:
I've added test packages compiled with gcc-4.7.2-1 (to be installed by
manually selecting them, like the test version of gcc itself):
FYI, 3.1.2 is out now.
I know, but since it is just a rollup of the three patches that are
already in thr test package I thought I'd wait until I get to roll the
final package.
Also, automating the patches is possible, e.g.:
PATCH_URI=$(seq -f http://www.mpfr.org/mpfr-${VERSION}/patch%02.0f 1 3)
Then use the '3' to control the number of patches available.
The problem wasn't really downloading the patches. The patch format
does not apply with the options that cygport tries, so you'll have to
apply it manually still.
Use docinto/dodoc as in GMP.
Yes, thanks for pointing that out — I'll clean up the package
definitions before release.
Question: Currently the documentation goes into the umbrella package.
Would it make sense to keep that package empty and have a separate doc
package. If yes, I'm leaning towards naming it libmpfr-doc rather than
mpfr-doc, but there doesn't seem to be a clear naming convention judging
from the existing packages.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: GCC-4.7.2-2: Go/No-go?
Dave Korn writes: I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs work and restores java and libffi. I've also been running the testsuite over the last few days and the results look quite reasonable. Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that I shouldn't release it until I've integrated all his patches. I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's worth uploading as a stop-gap to address the mentioned problems and integrating Yaakov's patches for the next release. To me it sounds like it should be released to get the recompiles going, but then I don't really know what exactly is in the patches Yaakov were talking about and if maybe they'd trigger another round of rebuilds. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: 64bit: cygstdc++-6.dll
On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote: Could you explain the necessity of the dllimport's in the same patch? The idea is to one day be able to move away from having auto-import enabled by default in binutils, so that .rdata can go back into the read-only-mapped .rdata section and be shared between processes as it ought. cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
On Wed, Apr 10, 2013 at 05:31:55PM +0200, Achim Gratz wrote: Dave Korn writes: I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs work and restores java and libffi. I've also been running the testsuite over the last few days and the results look quite reasonable. Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that I shouldn't release it until I've integrated all his patches. I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's worth uploading as a stop-gap to address the mentioned problems and integrating Yaakov's patches for the next release. To me it sounds like it should be released to get the recompiles going, but then I don't really know what exactly is in the patches Yaakov were talking about and if maybe they'd trigger another round of rebuilds. It isn't clear to me why we'd be spending days discussing this when presumably the patches apply without too much effort. Some of the patches here: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc look worthwhile to me. If we're talking about only gcc 4.7 fixes then it looks like we're only talking about five patches, none of them are to source files, and none of them are very big.
Re: 64 bit: noarch packages and going beta
Corinna Vinschen writes: - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? I haven't used it for a longer stretch than a few hours at a time, but I've compiled some fairly complex packages and ran their testsuites without any obvious problems on a real machine (not VM) with four cores. I'd say it would certainly benefit from a wider base of different testing environments and workloads, so go beta. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITA] ppl / cloog-ppl
Yaakov (Cygwin/X) writes: When installing, make sure you de-install all old packages to avoid old files sticking around due to the package renames. We can create obsolete packages to handle the renames; just remind me in the RFU. If that just entails creating an empty package ppl-devel and putting it into category _obsolete, then I can do that. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: 64bit: cygstdc++-6.dll
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. 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 10/04/2013 16:47, Christopher Faylor wrote: It isn't clear to me why we'd be spending days discussing this when presumably the patches apply without too much effort. Some of the patches here: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc look worthwhile to me. If we're talking about only gcc 4.7 fixes then it looks like we're only talking about five patches, none of them are to source files, and none of them are very big. It takes 11 hours on a triple-core machine at -j6 to build and package GCC. In order to guarantee consistent reproduction I always respin the built package from -src package through two generations. It then takes three to five days to run enough of the testsuite to be confident that the packaged compiler works well. So it'd be next week at the earliest. Hence I'm uploading 4.7.2-2 now. cheers, DaveK
Re: [ITP] hostname 3.12 (Attn: coreutils maintainer)
Corinna Vinschen wrote: On Apr 10 09:57, Corinna Vinschen wrote: On Apr 9 22:55, Christian Franke wrote: I would like to contribute the (Debian) Linux version of hostname(1) and would suggest to remove the GNU hostname command from coreutils package. This version of hostname allows to show the FQDN (-f), DNS domain name (-d, dnsdomainname), alias names (-a, -A) or network addresses (-i, -I). Works reasonably on Cygwin. It is a slightly patched version of hostname 3.12 from Debian unstable which is at least also used on Fedora. http://packages.debian.org/unstable/hostname The packages below are intended for testing. Command and man page are installed as hostname-linux with the usual symlinks domainname and dnsdomainname. This should keep hostname from coreutils intact. [...] I'm just generating a 64 bit coreutils package without hostname. If you provide a new 64 bit package with hostname being called hostname, I could upload them together later today. Just FYI, the hostnameless coreutils package is ready for upload. New 64bit package with command named hostname, category changed to Base: wget -r -nH --cut-dirs=2 \ http://franke.dvrdns.org/cygwin/release/64bit/hostname2/hostname-3.12-1-src.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/64bit/hostname2/hostname-3.12-1.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/64bit/hostname2/hostname-debuginfo/hostname-debuginfo-3.12-1.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/64bit/hostname2/hostname-debuginfo/setup.hint \ http://franke.dvrdns.org/cygwin/release/64bit/hostname2/setup.hint 32bit Version: wget -r -nH --cut-dirs=2 \ http://franke.dvrdns.org/cygwin/release/hostname2/hostname-3.12-1-src.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/hostname2/hostname-3.12-1.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/hostname2/hostname-debuginfo/hostname-debuginfo-3.12-1.tar.bz2 \ http://franke.dvrdns.org/cygwin/release/hostname2/hostname-debuginfo/setup.hint \ http://franke.dvrdns.org/cygwin/release/hostname2/setup.hint Christian
Re: 64 bit: noarch packages and going beta
On 4/10/2013 3:16 PM, Corinna Vinschen wrote: Greetings venerable maintainers, - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? 64bit looks solid enough, the recv mismatch was the only real problem I had in porting packages. Wider audience is needed to test more corner cases Thanks for your input, Corinna Regards Marco
Re: [ITP] hostname 3.12 (Attn: coreutils maintainer)
On Apr 10 18:59, Christian Franke wrote: Corinna Vinschen wrote: On Apr 10 09:57, Corinna Vinschen wrote: On Apr 9 22:55, Christian Franke wrote: I would like to contribute the (Debian) Linux version of hostname(1) and would suggest to remove the GNU hostname command from coreutils package. [...] I'm just generating a 64 bit coreutils package without hostname. If you provide a new 64 bit package with hostname being called hostname, I could upload them together later today. Just FYI, the hostnameless coreutils package is ready for upload. New 64bit package with command named hostname, category changed to Base: [...] 64 bit version uploaded, together with the new hostname-less coreutils package. But I almost screwed this up. You renamed the dir to hostname2, even though the package is called hostname. That was a teeny little bit confusing... 32bit Version: [...] I leave the 32 bit update to Eric. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [ITP] hostname 3.12 (Attn: coreutils maintainer)
Corinna Vinschen wrote: On Apr 10 18:59, Christian Franke wrote: New 64bit package with command named hostname, category changed to Base: [...] 64 bit version uploaded, together with the new hostname-less coreutils package. But I almost screwed this up. You renamed the dir to hostname2, even though the package is called hostname. That was a teeny little bit confusing... Sorry, I forgot to mention this. I intentionally renamed the directory to avoid that someone who wants the test package installs the final package. Was probably counter-productive in this case... Christian
Re: [ITP] libffi (attn: Dave Korn)
On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote: On 2013-04-10 04:29, Corinna Vinschen wrote: On Apr 10 04:06, Yaakov (Cygwin/X) wrote: libffi development moved out of GCC into a separate project a long time ago; the copy included in GCC is used for libgcj, but only as a convenience (static) library, and it is usually a few point releases behind the standalone version. Finally, last month, GCC was patched upstream to stop installing its copy (a similar patch for 4.7.2 and 4.8.0 is in Ports git). Therefore I think the time has arrived to join Fedora and Debian and switch i686 to the standalone version. (We are already using this for x86_64.) This will also simplify building many of the ~20 packages which use libffi and expect the .pc file provided only by the standalone version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi ftp://ftp.cygwinports.org/pub/cygwinports/temp/libffi/ Isn't that independent from what gcc itself does? If so, feel free to upload. Only the man3 pages collide with gcc4-core. But gcc's libffi.dll.a will take priority over the one in /usr/lib (see gcc -print-search-dirs), so manual intervention will be necessary until our gcc stops shipping libffi. Okeydokey. Upstream libffi generates cygffi-6.dll, so what I'll do is incorporate the patch (along with your others) into 4.7.3-1 (which will be a full curr: version release), and ship one last version of libffi4 (marked obsolete) with that but make sure the man pages, static import lib etc (-devel stuff basically) is not packaged. That'll probably be in ten days or so, at which point you can upload the standalone libffi. Makes sense? cheers, DaveK
[ITP] perl-Text-CSV, perl-Text-CSV_XS
Packages for manipulating comma-separated text files in Perl.
Found in several distros: http://pkgs.org/search/?keyword=perl-Text-CSV
# 32-bit
BASEURL=https://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=4 \
${BASEURL}/uVaNvKwqAl/release/perl/perl-Text-CSV/setup.hint \
${BASEURL}/ZI2VlFVvzh/release/perl/perl-Text-CSV/perl-Text-CSV-1.21-1.tar.bz2
\
${BASEURL}/r07-JuPv3i/release/perl/perl-Text-CSV/perl-Text-CSV-1.21-1-src.tar.bz2
\
${BASEURL}/m2cEAoF7IY/release/perl/perl-Text-CSV_XS/setup.hint \
${BASEURL}/A6j9TzhaTr/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-0.97-1.tar.bz2
\
${BASEURL}/8pWZm-Mn7Z/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-0.97-1-src.tar.bz2
\
${BASEURL}/EDzsvLRHl9/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-debuginfo/setup.hint
\
${BASEURL}/CXbwm5X0mQ/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-debuginfo/perl-Text-CSV_XS-debuginfo-0.97-1.tar.bz2
# 64-bit
BASEURL=https://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/kX7mDjmu-S/64bit/release/perl/perl-Text-CSV/setup.hint \
${BASEURL}/9ryDzPxyKg/64bit/release/perl/perl-Text-CSV/perl-Text-CSV-1.21-1.tar.bz2
\
${BASEURL}/j8TKLTBOFJ/64bit/release/perl/perl-Text-CSV/perl-Text-CSV-1.21-1-src.tar.bz2
\
${BASEURL}/FNArt1rDYS/64bit/release/perl/perl-Text-CSV_XS/setup.hint \
${BASEURL}/fQzsh_fR6P/64bit/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-0.97-1.tar.bz2
\
${BASEURL}/-HwcJb9Tmv/64bit/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-0.97-1-src.tar.bz2
\
${BASEURL}/n-xXlSEaG7/64bit/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-debuginfo/setup.hint
\
${BASEURL}/3U8618fOnt/64bit/release/perl/perl-Text-CSV_XS/perl-Text-CSV_XS-debuginfo/perl-Text-CSV_XS-debuginfo-0.97-1.tar.bz2
Many thanks in advance for looking at this package,
Dave.
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. cheers, DaveK
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
On 11/04/2013 02:05, Dave Korn wrote: On 11/04/2013 01:18, Christopher Faylor wrote: gcc won't be available until this is fixed. Oops. I'll just edit it on the server. Sorry for the inconvenience. Should be ok now I trust. Apologies once more, I've updated my local hint file in svn to prevent it happening again. cheers, DaveK
Re: [ITP] libffi (attn: Dave Korn)
On 2013-04-10 16:34, Dave Korn wrote: On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote: Only the man3 pages collide with gcc4-core. But gcc's libffi.dll.a will take priority over the one in /usr/lib (see gcc -print-search-dirs), so manual intervention will be necessary until our gcc stops shipping libffi. Okeydokey. Upstream libffi generates cygffi-6.dll, so what I'll do is incorporate the patch (along with your others) into 4.7.3-1 (which will be a full curr: version release), and ship one last version of libffi4 (marked obsolete) with that but make sure the man pages, static import lib etc (-devel stuff basically) is not packaged. That'll probably be in ten days or so, at which point you can upload the standalone libffi. Makes sense? After applying my libffi-noinst.patch, all you really need to do is remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro until all libffi-dependent packages are rebuilt (most of which are mine). Yaakov
Re: [ITP] libffi (attn: Dave Korn)
On 11/04/2013 02:33, Yaakov (Cygwin/X) wrote: After applying my libffi-noinst.patch, all you really need to do is remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro until all libffi-dependent packages are rebuilt (most of which are mine). Surely there'll be a problem if the curr: version of everything else goes to 4.7.3-1 but there's no matching version of libffi4? cheers, DaveK
Re: GCC-4.7.2-2: Go/No-go?
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. 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? I don't understand why there's a libquadmath0-devel; like the other C libraries, this should just be part of gcc-core. 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. Also, could you please explain the reasons for the ehdebug, execstack, and shared-libgcc patches? Yaakov
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
On 2013-04-10 10:27, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
Also, automating the patches is possible, e.g.:
PATCH_URI=$(seq -f http://www.mpfr.org/mpfr-${VERSION}/patch%02.0f 1 3)
Then use the '3' to control the number of patches available.
The problem wasn't really downloading the patches. The patch format
does not apply with the options that cygport tries, so you'll have to
apply it manually still.
Only 'allpatches' doesn't apply; the individual ones do sequentially.
Question: Currently the documentation goes into the umbrella package.
Would it make sense to keep that package empty and have a separate doc
package. If yes, I'm leaning towards naming it libmpfr-doc rather than
mpfr-doc, but there doesn't seem to be a clear naming convention judging
from the existing packages.
Unfortunately we don't have consistent naming convention, but a -doc
package would be preferred IMO.
Yaakov
Re: [ITP] libffi (attn: Dave Korn)
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. Yaakov
Re: 64 bit: noarch packages and going beta
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
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).
Yaakov
Re: upset: *** setup.ini: warning - package gcc4-java requires non-existent package java-ecj
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
Re: [ITA] mpfr (libmpfr-devel / libmpfr4)
Yaakov (Cygwin/X) writes: The problem wasn't really downloading the patches. The patch format does not apply with the options that cygport tries, so you'll have to apply it manually still. Only 'allpatches' doesn't apply; the individual ones do sequentially. Let me try again, but they didn't when I tried yesterday, but I was admittedly in a bit of a hurry and may have overlooked something. Unfortunately we don't have consistent naming convention, but a -doc package would be preferred IMO. I'll make it so, then. Could you (or anyone else) make a suggestion for a package naming convention? WITH the 64bit distribution looming I'd think that effort would be well spent. Thanks. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: GCC-4.7.2-2: Go/No-go?
d.henman writes: [...] Please keep that conversation on the cygwin-apps list. The audience there is more appropriate for what Dave K was asking. ..mark -- 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: rsync: writefd_unbuffered failed (when writing to micro SD cards)
Update: Sometimes it dies randomly and sometimes it dies on a specific file. If I copy the file manually, it works. The file shows no signs of corruption on the micro SD card. Also, the micro SD card has a FAT32 filesystem. Christopher de Vidal On Sat, Apr 6, 2013 at 7:20 PM, Christopher de Vidal cbdevidal@gmail.com wrote: I'm using rsync 3.0.9-1 to copy several directories to 32GB micro SD cards in both WinXP and Win7. I randomly get this error message; Please help me to debug it: rsync: writefd_unbuffered failed to write 127 bytes to socket [generator]: Broken pipe (32) I've got rsync on an infinite while loop so it keeps retrying, and it copies a little more each time, dying at different places each time. It has happened on all of my SD cards and with multiple SD card readers/phones/tablets, copying from two different computers. The only constant is the hard drive (moved from one computer to the other) but it's not exhibiting other symptoms of early failure. The directories are various sizes but one of the directories is only 231MB with 417 files/7 folders. The smallest file is only a few bytes and the largest file is 109MB. Here's the command which syncs the 231MB directory: rsync --modify-window=10 --recursive --times --verbose --delete --timeout=10 --human-readable --progress --omit-dir-times --no-compress --inplace --partial --bwlimit=1000 Appropriate_technology /cygdrive/f/C I added --no-compress --inplace --partial --bwlimit=1000 after searching Google. No good. I have multiple commands like these for multiple directories. When I put just this command in a loop by itself, it works, but when I put multiple commands, one of them will randomly generate that error message. My .bashrc and .bash_profile are untouched from the install, as are /etc/bash.bashrc and /etc/profile, etc. I'm certain I haven't tweaked my environment. Just a typical install. Ran checkdisk on the drive before attempting again. Cygwin setup version 2.774 Bash version 4.1.10-4 base-cygwin 3.1-1 cygwin 1.7.17-1 cygwin1.dll version 1.7.17 Windows 7 64-bit Service Pack 1 Intel E2200 2.20GHz Dual Core CPU 4GB RAM Not swapping or maxed CPU or anything. Christopher de Vidal -- 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
Cron Service Cannot Start: System error 1069 has occurred.
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. 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. I've attached cygcheck.out for your reference and I manage to change some information there by replacing it with XXX or xxx. Hoping for your quick assessment of my problem. Thanks. Regards, Jun cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Please try the latest snapshot
The latest snapshot has some more signal-handling restructuring. I'd appreciate it if people would check it out. 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: Please try the latest snapshot
On Wed, Apr 10, 2013 at 09:20:26AM -0400, Christopher Faylor wrote: The latest snapshot has some more signal-handling restructuring. I'd appreciate it if people would check it out. http://cygwin.com/snapshots/ -- 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: bash-completion load times
Gary Johnson wrote: Cygwin's bash-completion package is version 1.3. Versions 1.9 and later use dynamic loading of completions that is supposed to improve the loading times. I think your best bet is to wait for the Cygwin package to be updated to the latest 2.1 version and see how that improves performance. Or just download and install it from source yourself. I'll give that a try when I have a chance, and report back on what difference it makes. That said, I'm surprised by the variation in load times of the files in /etc/bash_completion.d that you observed. Those files all start with a call to the have() function which should abort further processing of the file if the corresponding program is not installed. The results I was seeing were pretty consistent. I'd guess the difference is due to either (a) some files being larger and thus taking significantly longer to parse, (b) calls to have() being slow in Cygwin for some reason, or (c) both. It should be relatively easy to distinguish between these experimentally. However if upgrading to a later version of bash-completion solves the problem, I suspect it won't be worth the effort. Adam -- 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
cannot find -levent
Hello, I have used cygwin for awhile now and love i, having an issue that is very confusing to me. So I am trying to install django-socketio via pip install django-socketio and after it succesffully I always get the error (I install things through pip all the time so I know pip is stable): //-- running build_ext building 'gevent.core' extension gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/include/python2.6 -c gevent/core.c -o build/temp.cygwin-1.7.9-i686-2.6/gevent/core.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.9-i686-2.6/gevent/core.o -L/home/tblank/.virtualenvs/raspberry_pi/lib/python2.6/config -levent -lpython2.6 -o build/lib.cygwin-1.7.9-i686-2.6/gevent/core.dll /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot find -levent collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 //- full error can be found here: http://dpaste.com/1053771/ I have installed libevent-2.0.21-stable from http://libevent.org/ ... and ran a ./configure, make and make install without any errors and I can see libevent.a in \usr\local\lib. I assume gcc can't find my library files for libevent but I have failed to find anything online that tells me how to tell gcc where those files are or if in fact that is the issue. Any information would be greatly appreciate. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cannot find -levent
On Wed, Apr 10, 2013 at 04:45:57PM +, Troy Blank wrote: Hello, I have used cygwin for awhile now and love i, having an issue that is very confusing to me. So I am trying to install django-socketio via pip install django-socketio and after it succesffully I always get the error (I install things through pip all the time so I know pip is stable): //-- running build_ext building 'gevent.core' extension gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/include/python2.6 -c gevent/core.c -o build/temp.cygwin-1.7.9-i686-2.6/gevent/core.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.9-i686-2.6/gevent/core.o -L/home/tblank/.virtualenvs/raspberry_pi/lib/python2.6/config -levent -lpython2.6 -o build/lib.cygwin-1.7.9-i686-2.6/gevent/core.dll /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot find -levent collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 //- full error can be found here: http://dpaste.com/1053771/ I have installed libevent-2.0.21-stable from http://libevent.org/ ... and ran a ./configure, make and make install without any errors and I can see libevent.a in \usr\local\lib. I assume gcc can't find my library files for libevent but I have failed to find anything online that tells me how to tell gcc where those files are or if in fact that is the issue. Any information would be greatly appreciate. Does adding -L/usr/local/lib to your gcc link line help? 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: cannot find -levent
Well like all things I struggle with it for hours and as soon as I ask for help I magically figure it out, anyway for anyone who wants to know how I did it I installed a beta release of gevent from http://code.google.com/p/gevent/downloads/list ... which doesn't use as many dependencies so it allowed django-socketio to install successfully, Thanks Everyone! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cannot find -levent
Troy Blank blanktroy at gmail.com writes: Well like all things I struggle with it for hours and as soon as I ask for help I magically figure it out, anyway for anyone who wants to know how I did it I installed a beta release of gevent from http://code.google.com/p/gevent/downloads/list ... which doesn't use as many dependencies so it allowed django-socketio to install successfully, Thanks Everyone! -- 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: perl 5.14 ncursesw: calling getbegyx() crashes
I got it working! And it's no issue with cygwin.
I had to build the Curses library by hand and edit the testsym.c and
list.syms. I suppose that the original version will compile fine on
Linux, but the compiler in cygwin complains about the LINES constant
in list.syms.
So here's what i've done. Maybe it will be usefull for someone:
~ $ export CURSES_LDFLAGS=-L/usr/lib/ncursesw -lncursesw
~ $ export CURSES_CFLAGS=-I/usr/include/ncursesw
~/Curses-1.28 $ perl Makefile.PL PANELS MENUS FORMS
GENfunction: not applicable
PANELS functions: enabled
MENUS functions: enabled
FORMS functions: enabled
WARNING: Your Curses form.h file appears to be in the default
system search path, which will not work for us because of
the conflicting Perl form.h file. This means your 'make' will
probably fail unless you fix this, as described in the INSTALL
file.
Writing Makefile for Curses
Writing MYMETA.yml
### Then i edited the files testsym.c and list.syms
~/Curses-1.28 $ make
### Now nearly every function will be found and compiled in.
~/Curses-1.28 $ make install
### Now the curses.dll should be insalled in /usr/lib/perl5/...
Here are the files i've edited:
testsym.c
==8==
#include c-config.h
main() {
int x,y; /*Add this line*/
SYM;
}
==8==
diff of list.syms
==8==
--- Curses-1.28/list.syms 2001-07-25 20:09:34.0 +0200
+++ Curses-1.28_new/list.syms 2013-04-10 17:52:38.871052800 +0200
@@ -16,7 +16,7 @@
E wattrset(stdscr,0)
E wstandend(stdscr)
E wstandout(stdscr)
-E wattr_get(stdscr,LINES,LINES,0)
+E wattr_get(stdscr,y,x,0)
E wattr_off(stdscr,0,0)
E wattr_on(stdscr,0,0)
E wattr_set(stdscr,0,0,0)
@@ -41,8 +41,8 @@
E init_color(0,0,0,0)
E has_colors()
E can_change_color()
-E color_content(0,LINES,LINES,LINES)
-E pair_content(0,LINES,LINES)
+E color_content(0,y,x,x)
+E pair_content(0,y,x)
E wdelch(stdscr)
E wdeleteln(stdscr)
E winsdelln(stdscr,0)
@@ -53,10 +53,10 @@
E KEY_F(0)
E wgetstr(stdscr,0)
E wgetnstr(stdscr,0,0)
-E getyx(stdscr,LINES,LINES)
-E getparyx(stdscr,LINES,LINES)
-E getbegyx(stdscr,LINES,LINES)
-E getmaxyx(stdscr,LINES,LINES)
+E getyx(stdscr,y,x)
+E getparyx(stdscr,y,x)
+E getbegyx(stdscr,y,x)
+E getmaxyx(stdscr,y,x)
E winch(stdscr)
E winchstr(stdscr,0)
E winchnstr(stdscr,0,0)
@@ -99,8 +99,8 @@
E reset_shell_mode()
E resetty()
E savetty()
-E getsyx(LINES,LINES)
-I getsyx(LINES,LINES)
+E getsyx(y,x)
+I getsyx(y,x)
E setsyx(0,0)
I setsyx(0,0)
E curs_set(0)
@@ -186,7 +186,7 @@
E ungetmouse(0)
E mousemask(0,LINES)
E wenclose(stdscr,0,0)
-E wmouse_trafo(stdscr,LINES,LINES,0)
+E wmouse_trafo(stdscr,y,x,0)
E mouseinterval(0)
E BUTTON_RELEASE(0,0)
E BUTTON_PRESS(0,0)
@@ -232,7 +232,7 @@
E pos_menu_cursor(0)
E menu_driver(0,0)
E set_menu_format(0,0,0)
-E menu_format(0,LINES,LINES)
+E menu_format(0,y,x)
E set_menu_items(0,0)
E menu_items(0)
E item_count(0)
@@ -254,7 +254,7 @@
E menu_win(0)
E set_menu_sub(0,stdscr)
E menu_sub(0)
-E scale_menu(0,LINES,LINES)
+E scale_menu(0,y,x)
E set_current_item(0,0)
E current_item(0)
E set_top_row(0,0)
@@ -276,7 +276,7 @@
E menu_request_name(0)
E menu_request_by_name(0)
E set_menu_spacing(0,0,0,0)
-E menu_spacing(0,LINES,LINES,LINES)
+E menu_spacing(0,y,x,x)
E pos_form_cursor(0)
E data_ahead(0)
E data_behind(0)
@@ -306,7 +306,7 @@
E form_win(0)
E set_form_sub(0,stdscr)
E form_sub(0)
-E scale_form(0,LINES,LINES)
+E scale_form(0,y,x)
E set_field_fore(0,0)
E field_fore(0)
E set_field_back(0,0)
@@ -318,8 +318,8 @@
E set_field_status(0,0)
E field_status(0)
E set_max_field(0,0)
-E field_info(0,LINES,LINES,LINES,LINES,LINES,LINES)
-E dynamic_field_info(0,LINES,LINES,LINES)
+E field_info(0,y,x,y,x,y,x)
+E dynamic_field_info(0,y,x,y,x)
E set_field_just(0,0)
E field_just(0)
E new_field(0,0,0,0,0,0)
==8==
Regards,
David
--
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
[ANNOUNCEMENT] Updated: postgresql-9.2.4-1
Version 9.2.4-1 of packages libecpg-compat2 libecpg-devel libecpg5 libpgtypes2 libpq-devel libpq5 postgresql postgresql-client postgresql-contrib postgresql-devel postgresql-doc postgresql-plperl postgresql-plpython are available in the Cygwin distribution: CHANGES New upstream security update. Full upstream changes: http://www.postgresql.org/docs/9.2/static/release-9-2-4.html http://www.postgresql.org/about/news/1456/ ADVISE for major version UPGRADE http://www.postgresql.org/support/versioning/ Major releases usually change the internal format of system tables and data files. These changes are often complex, so we do not maintain backward compatibility of all stored data. A dump/reload of the database or use of the pg_upgrade module is required for major upgrades. DESCRIPTION PostgreSQL is a powerful, open source object-relational database system. It has a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types HOMEPAGE http://www.postgresql.org Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
[ANNOUNCEMENT] Updated: experimental package: gcc4-4.7.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This is a test release of GCC 4.7.2 which replaces the earlier test release. It reverts the package dependencies in the Cygwin repository to those that are correct for the current full version of GCC, 4.5.3-3, as setup.exe can only support one set of dependencies for all versions of a package. This means you may need to select some of the new packages manually, depending on the set of languages you are installing; see the important note section in From the README below. In addition, this release restores libffi and java which were unavailable from the previous test version. It also makes linking against shared libgcc the default for executables as well as DLLs, which is necessary for correct sharing of thread-local variables imported by executables from DLLs. I would like to express my gratitude to JonY for stepping into the breach caused by my absence from the Cygwin community and releasing the first test version of GCC 4.7 series. He did a very difficult job and did it well and deserves the highest of praise for doing so. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a test version release, you will need to manually select any packages and dependent libraries you require: see below for full details. NEWS From the README: IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES === Cygwin's setup.exe does not handle a situation where an experimental package version has different dependencies from the main current version. For this reason, the dependencies listed in the Cygwin package repository are those required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be correct for the majority of users. Anyone wishing to install the test version of GCC will need to ensure they select manually select the corresponding new versions of the runtime libraries required. These dependencies are: gcc4-java: Requires libgcj13. gcc4-objc: Requires libobjc4. gcc4-ada: Requires libgnat4.7. gcc4-fortran: Requires libquadmath0, libquadmath0-devel. libgfortran3: Requires libquadmath0. Cygwin port maintained by: Dave Korn dave.korn.cygwin AT gmail.com.use.the.list.please Please address all questions to the main Cygwin mailing list. This is the key used for signing Cygwin GCC releases: pub 1024D/6A388C3E 2008-05-31 uid Dave Korn (release signing key) dave.korn.cygwin AT gmail.com sub 4096g/D4E41590 2008-05-31 Also available at a key-server near you! - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (Cygwin) mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR 8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8 d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9 ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO 10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5 CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52 +MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S 0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP 2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi 5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh
1.7.15: gcc fails to load: missing cygmpfr-4.dll
I have just installed cygwin on this system. When I try to compile a small program, I get this error: /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory ldd agrees: 11:47:53$ ldd /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe ntdll.dll = /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c90) kernel32.dll = /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80) cygcloog-0.dll = /usr/bin/cygcloog-0.dll (0x6ff7) cyggcc_s-1.dll = /cygdrive/c/WINDOWS/cyggcc_s-1.dll (0x67f0) cygwin1.dll = /cygdrive/c/WINDOWS/cygwin1.dll (0x6100) ADVAPI32.DLL = /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77dd) RPCRT4.dll = /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e7) Secur32.dll = /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fe) cyggmp-3.dll = /usr/bin/cyggmp-3.dll (0x6fbb) cygppl_c-2.dll = /usr/bin/cygppl_c-2.dll (0x6f17) cygppl-7.dll = /usr/bin/cygppl-7.dll (0x6f3e) cygstdc++-6.dll = /usr/bin/cygstdc++-6.dll (0x6f0a) cyggmpxx-4.dll = /usr/bin/cyggmpxx-4.dll (0x6fba) cygiconv-2.dll = /cygdrive/c/WINDOWS/cygiconv-2.dll (0x674c) cygintl-8.dll = /cygdrive/c/WINDOWS/cygintl-8.dll (0x6f5c) cygmpc-1.dll = /usr/bin/cygmpc-1.dll (0x6f91) cygmpfr-1.dll = /usr/bin/cygmpfr-1.dll (0x6f8c) cygmpfr-4.dll = not found cygz.dll = /usr/bin/cygz.dll (?) Where would I find this library? (source not much help w/out working compiler :-/ Cheers ... Duncan. cygcheck.out Description: cygcheck.out -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.15: gcc fails to load: missing cygmpfr-4.dll
On 4/10/2013 9:57 PM, Duncan Roe wrote: Where would I find this library? http://cygwin.com/cgi-bin2/package-grep.cgi?grep=cygmpfr-4.dll -- 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
1.7.15 gcc post-install fails altdir /etc/alternatives invalid
Fresh install on this system. Installer reports errors: on checking setup.log.full I see errors like 2013/04/11 11:07:36 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/gcc4-fortran.sh altdir /etc/alternatives invalid 2013/04/11 11:07:36 abnormal exit: exit code=2 2013/04/11 11:07:36 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/automake.sh altdir /etc/alternatives invalid The error altdir /etc/alternatives invalid comes from the alternatives command. I get it when /etc/alternatives is empty or when it has valid symbolic links. The Fortran script: 12:14:12$ cat /etc/postinstall/gcc4-fortran.sh /usr/sbin/update-alternatives \ --install /usr/bin/gfortran.exe gfortran /usr/bin/gfortran-4.exe 40 \ --slave /usr/bin/i686-pc-cygwin-gfortran.exe i686-pc-cygwin-gfortran /usr/bin/i686-pc-cygwin-gfortran-4.exe \ --slave /usr/share/man/man1/gfortran.1.gz gfortran.1.gz /usr/share/man/man1/gfortran-4.1.gz \ WORK AROUND usr/sbin/update-alternatives was a symlink to usr/sbin/alternatives.exe. I found the original update-alternatives Perl script and installed that. Then I re-ran the post update scripts by hand (and renamed them .done by hand). Unfortunately the next install resets update-alternatives to be a symlink, so this always has to be a manual process. I guess you have the source for alternatives.exe on your site somewhere - I couldn't find it on the Web. Cheers ... Duncan. cygcheck.out Description: cygcheck.out update-alternatives Description: update-alternatives -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.15: gcc fails to load: missing cygmpfr-4.dll
On 11/04/2013 02:57, Duncan Roe wrote: I have just installed cygwin on this system. When I try to compile a small program, I get this error: /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe: error while loading shared libraries: cygmpfr-4.dll: cannot open shared object file: No such file or directory Sorry about that, I missed a dependency when I uploaded it. It's actually fixed as of a few hours ago, but the fix must not have reached your mirror yet. Just use setup.exe to install libmpfr4. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
GCC can't find its header directoriescy
Thanks guys for the pointers to cygmpfr-4.dll. Got it. This problem with headers started happening on an old installation so I reinstalled but it still happens: 12:31:51$ gcc -v strerror.c -o strerror Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5. --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc -- atarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr= usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_a exit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enab e-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix - with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.5.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'strerror.exe' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../ ./../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../i nclude/w32api strerror.c -quiet -dumpbase strerror c -mtune=generic -march=i686 -auxbase strerror -version -o /tmp/ccShhRJ9.s GNU C (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/include-fixed ignoring nonexistent directory /usr/i686-pc-cygwin/include ignoring nonexistent directory /usr/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../ include/w32api #include ... search starts here: #include ... search starts here: End of search list. GNU C (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 89d6774c1d510265da7d48b735ce61fb strerror.c:2:19: error: no include path in which to search for stdio.h strerror.c:3:20: error: no include path in which to search for string.h strerror.c:4:19: error: no include path in which to search for errno.h strerror.c:5:23: error: no include path in which to search for sys/types.h strerror.c:6:20: error: no include path in which to search for signal.h strerror.c: In function `main': strerror.c:14:7: warning: incompatible implicit declaration of built-in function `strchr' strerror.c:15:15: warning: incompatible implicit declaration of built-in function `strrchr' strerror.c:18:5: warning: incompatible implicit declaration of built-in function `fprintf' strerror.c:18:13: error: `stderr' undeclared (first use in this function) strerror.c:18:13: note: each undeclared identifier is reported only once for each function it appears in strerror.c:21:7: warning: incompatible implicit declaration of built-in function `sscanf' strerror.c:23:5: warning: incompatible implicit declaration of built-in function `fprintf' strerror.c:27:7: warning: assignment makes pointer from integer without a cast strerror.c:29:7: warning: assignment makes pointer from integer without a cast strerror.c:32:5: error: `errno' undeclared (first use in this function) strerror.c:34:5: warning: incompatible implicit declaration of built-in function `snprintf' strerror.c:39:5: warning: incompatible implicit declaration of built-in function `fprintf' strerror.c:44:3: warning: incompatible implicit declaration of built-in function `printf' 12:33:27$ ls /usr/include FlexLexer.h arpacommline.h elf.h features.h ieeefp.hmagic.h newlib.hregex.h stdlib.hticker.h wctype.h IEEE.h asm complex.h endian.h fenv.h ifaddrs.h malloc.hobjstack.h resolv.h string.htime.h wordexp.h _ansi.h assert.hcrypt.h envlock.h
FW: GCC can't find its header directories: test C file
Sorry - meant to include source so you can easily test, Cheers ... Duncan. -Original Message- From: Duncan Roe Sent: Thursday, 11 April 2013 3:13 PM To: cygwin. Subject: GCC can't find its header directoriescy Thanks guys for the pointers to cygmpfr-4.dll. Got it. This problem with headers started happening on an old installation so I reinstalled but it still happens: SNIP strerror.c Description: strerror.c -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC can't find its header directoriescy
On 11/04/2013 06:12, Duncan Roe wrote: Thanks guys for the pointers to cygmpfr-4.dll. Got it. This problem with headers started happening on an old installation so I reinstalled but it still happens: ignoring nonexistent directory /usr/include strerror.c:2:19: error: no include path in which to search for stdio.h 12:33:27$ ls /usr/include locale.hnetdb.h reent.h stdio.h termios.h wait.h /usr/include definitely exists but gcc / cpp claims it does not. Since this just started happening I wonder whether it is caused by some update to Windows. (Win XP SP3). Anyone else seen anything like it? I'm stuck, Bizarre. I've never seen anything like it, nor your problem with altdir invalid. However I've got one guess about what might be interfering, from your cygcheck.out: 45k 2010/08/15 C:\WINDOWS\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0 cyggcc_s-1.dll v0.0 ts=2010/8/15 8:57 982k 2009/12/23 C:\WINDOWS\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0 cygiconv-2.dll v0.0 ts=2009/12/24 0:25 31k 2011/11/28 C:\WINDOWS\cygintl-1.dll - os=4.0 img=1.0 sys=4.0 cygintl-8.dll v0.0 ts=2009/4/3 12:15 31k 2009/04/03 C:\WINDOWS\cygintl-2.dll - os=4.0 img=1.0 sys=4.0 cygintl-8.dll v0.0 ts=2009/4/3 12:15 31k 2009/04/03 C:\WINDOWS\cygintl-8.dll - os=4.0 img=1.0 sys=4.0 cygintl-8.dll v0.0 ts=2009/4/3 12:15 224k 2010/06/15 C:\WINDOWS\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0 cygpcre-0.dll v0.0 ts=2010/6/15 14:10 10k 2009/12/14 C:\WINDOWS\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0 cygsigsegv-2.dll v0.0 ts=2009/12/14 23:56 2586k 2010/08/31 C:\WINDOWS\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 17:58 Cygwin DLL version info: DLL version: 1.7.7 Those could well have been interfering. Get rid of all Cygwin-related DLLs from your C:\WINDOWS folder (maybe stash them away somewhere safe in case they turn out to be needed by some Cygwin-dependent application you've got on your system), then reinstall everything using setup.exe (click on Default next to the All category in the Category view until it switches to Reinstall, ignore the couple of warning boxes that pop up on the way there) and see if it all works better once that's completed. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: experimental package: gcc4-4.7.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This is a test release of GCC 4.7.2 which replaces the earlier test release. It reverts the package dependencies in the Cygwin repository to those that are correct for the current full version of GCC, 4.5.3-3, as setup.exe can only support one set of dependencies for all versions of a package. This means you may need to select some of the new packages manually, depending on the set of languages you are installing; see the important note section in From the README below. In addition, this release restores libffi and java which were unavailable from the previous test version. It also makes linking against shared libgcc the default for executables as well as DLLs, which is necessary for correct sharing of thread-local variables imported by executables from DLLs. I would like to express my gratitude to JonY for stepping into the breach caused by my absence from the Cygwin community and releasing the first test version of GCC 4.7 series. He did a very difficult job and did it well and deserves the highest of praise for doing so. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a test version release, you will need to manually select any packages and dependent libraries you require: see below for full details. NEWS From the README: IMPORTANT NOTE ABOUT DEPENDENCIES AND RUNTIME LIBRARIES === Cygwin's setup.exe does not handle a situation where an experimental package version has different dependencies from the main current version. For this reason, the dependencies listed in the Cygwin package repository are those required by the mainstream (4.5.3-3) release of Cygwin GCC, as those will be correct for the majority of users. Anyone wishing to install the test version of GCC will need to ensure they select manually select the corresponding new versions of the runtime libraries required. These dependencies are: gcc4-java: Requires libgcj13. gcc4-objc: Requires libobjc4. gcc4-ada: Requires libgnat4.7. gcc4-fortran: Requires libquadmath0, libquadmath0-devel. libgfortran3: Requires libquadmath0. Cygwin port maintained by: Dave Korn dave.korn.cygwin AT gmail.com.use.the.list.please Please address all questions to the main Cygwin mailing list. This is the key used for signing Cygwin GCC releases: pub 1024D/6A388C3E 2008-05-31 uid Dave Korn (release signing key) dave.korn.cygwin AT gmail.com sub 4096g/D4E41590 2008-05-31 Also available at a key-server near you! - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (Cygwin) mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR 8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8 d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9 ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO 10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5 CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52 +MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S 0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP 2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi 5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh
