Re: Please build 64 bit packages
On Jul 31 18:23, Yaakov (Cygwin/X) wrote: On 2013-07-25 07:15, Corinna Vinschen wrote: now that the 64 bit version is in the wild, it would be incredibly cool if you could all have a look into building your packages, which are not yet available, for the 64 bit distro. Alternatively, for those of your packages which are noarch packages, for instance perl or python scripts, please drop us a note here along the lines of please copy package foo from 32 to 64 bit distro. I just copied over the newest version of all noarch packages whose deps are available. Ignoring obsolete packages, as of this moment, the diffstat between the arches is +81/-316. Cool, many thanks! How did you generate the diffstat? The numbers indicate a lot of preliminary work before running the tool since a simple diff returns numbers along the lines of -1000/+1500. So I'm wondering, do you have a list of important packages (like, say, ocaml, inetutils, any libs) still missing? It might help to get a better picture of the state of the x86_64 distro. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Please build 64 bit packages
On 2013-08-01 02:57, Corinna Vinschen wrote:
On Jul 31 18:23, Yaakov (Cygwin/X) wrote:
I just copied over the newest version of all noarch packages whose
deps are available. Ignoring obsolete packages, as of this moment,
the diffstat between the arches is +81/-316.
Cool, many thanks!
How did you generate the diffstat? The numbers indicate a lot of
preliminary work before running the tool since a simple diff returns
numbers along the lines of -1000/+1500.
First off, I'm basing my numbers on *source* packages. I then removed
all obsolete packages from the i686 list, as well as the cygwin{32,64}-*
packages from both lists (since those aren't really relevant to this
discussion). A copy of my list is at
sourceware:~yselkowitz/TODO_DISTRO_X64.diff.
So I'm wondering, do you have a list of important packages (like,
say, ocaml, inetutils, any libs) still missing? It might help to
get a better picture of the state of the x86_64 distro.
I'd say llvm, nspr, ocaml and postgresql are the most noticeable missing
prereqs at the moment. The first two are mine, but they require
significant porting work (particularly llvm), and I've been focused on
other packages. There are a few other minor libraries missing, but the
rest looks to be mostly programs that just need a rebuild.
Yaakov
Re: Please build 64 bit packages
On Aug 1 03:40, Yaakov (Cygwin/X) wrote:
On 2013-08-01 02:57, Corinna Vinschen wrote:
On Jul 31 18:23, Yaakov (Cygwin/X) wrote:
I just copied over the newest version of all noarch packages whose
deps are available. Ignoring obsolete packages, as of this moment,
the diffstat between the arches is +81/-316.
Cool, many thanks!
How did you generate the diffstat? The numbers indicate a lot of
preliminary work before running the tool since a simple diff returns
numbers along the lines of -1000/+1500.
First off, I'm basing my numbers on *source* packages. I then
removed all obsolete packages from the i686 list, as well as the
cygwin{32,64}-* packages from both lists (since those aren't really
relevant to this discussion). A copy of my list is at
sourceware:~yselkowitz/TODO_DISTRO_X64.diff.
Thanks.
So I'm wondering, do you have a list of important packages (like,
say, ocaml, inetutils, any libs) still missing? It might help to
get a better picture of the state of the x86_64 distro.
I'd say llvm, nspr, ocaml and postgresql are the most noticeable
missing prereqs at the moment. The first two are mine, but they
require significant porting work (particularly llvm), and I've been
focused on other packages. There are a few other minor libraries
missing, but the rest looks to be mostly programs that just need a
rebuild.
I could take your diff and generate a missing packages list with
maintainer names from there and publish it here on cygwin-apps.
I could do this every few weeks, so we could keep a porting progress
and discussion platform to discuss the dependencies which still have
to be resolved.
Does that sounds useful?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
tftp for x86_64 uploaded (was Re: Please build 64 bit packages)
On Aug 1 11:05, Corinna Vinschen wrote:
On Aug 1 03:40, Yaakov (Cygwin/X) wrote:
On 2013-08-01 02:57, Corinna Vinschen wrote:
On Jul 31 18:23, Yaakov (Cygwin/X) wrote:
I just copied over the newest version of all noarch packages whose
deps are available. Ignoring obsolete packages, as of this moment,
the diffstat between the arches is +81/-316.
Cool, many thanks!
How did you generate the diffstat? The numbers indicate a lot of
preliminary work before running the tool since a simple diff returns
numbers along the lines of -1000/+1500.
First off, I'm basing my numbers on *source* packages. I then
removed all obsolete packages from the i686 list, as well as the
cygwin{32,64}-* packages from both lists (since those aren't really
relevant to this discussion). A copy of my list is at
sourceware:~yselkowitz/TODO_DISTRO_X64.diff.
Thanks.
So I'm wondering, do you have a list of important packages (like,
say, ocaml, inetutils, any libs) still missing? It might help to
get a better picture of the state of the x86_64 distro.
I'd say llvm, nspr, ocaml and postgresql are the most noticeable
missing prereqs at the moment. The first two are mine, but they
require significant porting work (particularly llvm), and I've been
focused on other packages. There are a few other minor libraries
missing, but the rest looks to be mostly programs that just need a
rebuild.
I could take your diff and generate a missing packages list with
maintainer names from there and publish it here on cygwin-apps.
I could do this every few weeks, so we could keep a porting progress
and discussion platform to discuss the dependencies which still have
to be resolved.
Does that sounds useful?
Btw., I just built and uploaded the tftp package for x86_64.
For some reason, even though inetutils is built without tftp
and tftpd support, it still needs the arp/tftp.h file provided
by the tftp package.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: Please build 64 bit packages
On 2013-08-01 04:05, Corinna Vinschen wrote: I could take your diff and generate a missing packages list with maintainer names from there and publish it here on cygwin-apps. I could do this every few weeks, so we could keep a porting progress and discussion platform to discuss the dependencies which still have to be resolved. Does that sounds useful? Yes, but right now we know people are waiting for ocaml and postgresql, so we can leave off their reverse deps for now. Yaakov
Re: Please build 64 bit packages
On Aug 1 04:20, Yaakov (Cygwin/X) wrote: On 2013-08-01 04:05, Corinna Vinschen wrote: I could take your diff and generate a missing packages list with maintainer names from there and publish it here on cygwin-apps. I could do this every few weeks, so we could keep a porting progress and discussion platform to discuss the dependencies which still have to be resolved. Does that sounds useful? Yes, but right now we know people are waiting for ocaml and postgresql, so we can leave off their reverse deps for now. Kind of tricky in case of ocaml. The requirements usually don't contain build time dependencies. I know now about orpie and unison, but there may be more. We could start with a simple list and add a waits for kind of information as we go along... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[64-bit Request for Testing] cppcheck-1.60.1-1
Hi All, I've cross compiled cppcheck for 64-bit and I'd appreciate it if someone with a 64-bit machine could give it a spin to confirm it works as expected: --- wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-1.60.1-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-1.60.1-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.60.1-1.tar.bz2 --- It compiled cleanly, so I'm hoping there are no issues. One thing I noticed is that cygport listed cygwin64-gcc-core as a dependency for cppcheck. Will this cause an issue when installed on 64-bit Cygwin? Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: [64-bit Request for Testing] cppcheck-1.60.1-1
On Aug 1 07:36, Chris Sutcliffe wrote: Hi All, I've cross compiled cppcheck for 64-bit and I'd appreciate it if someone with a 64-bit machine could give it a spin to confirm it works as expected: --- wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-1.60.1-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-1.60.1-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.60.1-1.tar.bz2 --- It compiled cleanly, so I'm hoping there are no issues. A quick test worked fine. Looks good, uploaded. One thing I noticed is that cygport listed cygwin64-gcc-core as a dependency for cppcheck. Will this cause an issue when installed on 64-bit Cygwin? This looks wrong. I removed this dependency manually for now. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Please build 64 bit packages
Il 8/1/2013 11:20 AM, Yaakov (Cygwin/X) ha scritto: On 2013-08-01 04:05, Corinna Vinschen wrote: I could take your diff and generate a missing packages list with maintainer names from there and publish it here on cygwin-apps. I could do this every few weeks, so we could keep a porting progress and discussion platform to discuss the dependencies which still have to be resolved. Does that sounds useful? Yes, but right now we know people are waiting for ocaml and postgresql, so we can leave off their reverse deps for now. building latest postgresql. I was sure it was already there.. Yaakov
packages with no known maintainer
Hi, while fiddling with the list of packages still missing in the 64 bit distro, I came across a handful of packages for which I neither found messages on cygwin-apps, nor on cygwin-announce in the archives. So, who's maintaining these packages: libxcwm perl-clone xtow xview Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: tftp for x86_64 uploaded (was Re: Please build 64 bit packages)
On 8/1/2013 5:18 AM, Corinna Vinschen wrote: Btw., I just built and uploaded the tftp package for x86_64. For some reason, even though inetutils is built without tftp and tftpd support, it still needs the arp/tftp.h file provided by the tftp package. stock inetutils assumes that tftp.h is provided by the system, for whatever reason: 2005-01-21 Alfred M. Szmidt ... * headers/Makefile.am (dist-hook): Target removed. (header_dirs): Variable removed. (EXTRA_DIST): Variable removed. * headers/confpaths.h.in, headers/crypt.h, headers/err.h, headers/getopt.h, headers/obstack.h, headers/osockaddr.h, headers/paths.h, headers/poll.h, headers/syslog-int.h, headers/arpa/DISTFILES, headers/arpa/ftp.h, headers/arpa/telnet.h, headers/arpa/tftp.h, headers/protocols/DISTFILES, headers/protocols/talkd.h: Files removed. In the past (e.g. when tftp[d].exe was compiled and shipped as part of the cygwin inetutils package), one of the custom cygwin patches was to add tftp.h and other headers back into the inetutils src tree -- and thence to install them onto the end user's system. However, when tftp[d].exe was split off (and built using a different upstream source code provider, which unlike inetutils supported IPv6) and Gernot took over maintainership, I removed those patches to inetutils and allowed the tftpd package to provide them instead. So, yes, there is a build dependency between inetutils and tftp now. -- Chuck
Re: packages with no known maintainer
Il 8/1/2013 3:15 PM, Corinna Vinschen ha scritto: Hi, while fiddling with the list of packages still missing in the 64 bit distro, I came across a handful of packages for which I neither found messages on cygwin-apps, nor on cygwin-announce in the archives. So, who's maintaining these packages: libxcwm perl-clone xtow xview Thanks, Corinna 3 are of Jon TURNEY http://cygwin.com/ml/cygwin-xfree-announce/2012-12/msg3.html http://cygwin.com/ml/cygwin-apps/2013-03/msg00017.html
Re: packages with no known maintainer
On Aug 1 15:21, marco atzeri wrote: Il 8/1/2013 3:15 PM, Corinna Vinschen ha scritto: Hi, while fiddling with the list of packages still missing in the 64 bit distro, I came across a handful of packages for which I neither found messages on cygwin-apps, nor on cygwin-announce in the archives. So, who's maintaining these packages: libxcwm perl-clone xtow xview Thanks, Corinna 3 are of Jon TURNEY Thanks! Your search skills are better than mine :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: tftp for x86_64 uploaded (was Re: Please build 64 bit packages)
On Aug 1 09:16, Charles Wilson wrote: On 8/1/2013 5:18 AM, Corinna Vinschen wrote: Btw., I just built and uploaded the tftp package for x86_64. For some reason, even though inetutils is built without tftp and tftpd support, it still needs the arp/tftp.h file provided by the tftp package. stock inetutils assumes that tftp.h is provided by the system, for whatever reason: 2005-01-21 Alfred M. Szmidt ... * headers/Makefile.am (dist-hook): Target removed. (header_dirs): Variable removed. (EXTRA_DIST): Variable removed. * headers/confpaths.h.in, headers/crypt.h, headers/err.h, headers/getopt.h, headers/obstack.h, headers/osockaddr.h, headers/paths.h, headers/poll.h, headers/syslog-int.h, headers/arpa/DISTFILES, headers/arpa/ftp.h, headers/arpa/telnet.h, headers/arpa/tftp.h, headers/protocols/DISTFILES, headers/protocols/talkd.h: Files removed. In the past (e.g. when tftp[d].exe was compiled and shipped as part of the cygwin inetutils package), one of the custom cygwin patches was to add tftp.h and other headers back into the inetutils src tree -- and thence to install them onto the end user's system. However, when tftp[d].exe was split off (and built using a different upstream source code provider, which unlike inetutils supported IPv6) and Gernot took over maintainership, I removed those patches to inetutils and allowed the tftpd package to provide them instead. So, yes, there is a build dependency between inetutils and tftp now. Makes sense. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64-bit Request for Testing] cppcheck-1.60.1-1
On 1 August 2013 08:04, Corinna Vinschen wrote: On Aug 1 07:36, Chris Sutcliffe wrote: It compiled cleanly, so I'm hoping there are no issues. A quick test worked fine. Looks good, uploaded. Thanks! Are we in the clear to send 64-bit announcements to the Announce mailing list now? One thing I noticed is that cygport listed cygwin64-gcc-core as a dependency for cppcheck. Will this cause an issue when installed on 64-bit Cygwin? This looks wrong. I removed this dependency manually for now. Thanks, I'll clean up my local copy as well. Yaakov, I'm assuming cygport is picking this up automatically, is there anyway it can be skipped, or is it something I'll need to keep an eye on going forward? Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: Please build 64 bit packages
Il 8/1/2013 2:48 PM, marco atzeri ha scritto: Il 8/1/2013 11:20 AM, Yaakov (Cygwin/X) ha scritto: On 2013-08-01 04:05, Corinna Vinschen wrote: I could take your diff and generate a missing packages list with maintainer names from there and publish it here on cygwin-apps. I could do this every few weeks, so we could keep a porting progress and discussion platform to discuss the dependencies which still have to be resolved. Does that sounds useful? Yes, but right now we know people are waiting for ocaml and postgresql, so we can leave off their reverse deps for now. building latest postgresql. I was sure it was already there.. Yaakov postgresql-9.2.4-2 uploaded
Re: [64-bit Request for Testing] cppcheck-1.60.1-1
On Aug 1 09:53, Chris Sutcliffe wrote: On 1 August 2013 08:04, Corinna Vinschen wrote: On Aug 1 07:36, Chris Sutcliffe wrote: It compiled cleanly, so I'm hoping there are no issues. A quick test worked fine. Looks good, uploaded. Thanks! Are we in the clear to send 64-bit announcements to the Announce mailing list now? Sure! As long as we're just filling up the 64 bit distro with packages already available and having the same version as in the 32 bit distro, you can handle that lazily as you see fit. One thing I noticed is that cygport listed cygwin64-gcc-core as a dependency for cppcheck. Will this cause an issue when installed on 64-bit Cygwin? This looks wrong. I removed this dependency manually for now. Thanks, I'll clean up my local copy as well. Yaakov, I'm assuming cygport is picking this up automatically, is there anyway it can be skipped, or is it something I'll need to keep an eye on going forward? Thanks, Chris Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Sorted list of packages missing in the 64 bit distro yet
Hi maintainers, from the list Yaakov generated today, I created another list of missing packages sorted by maintainer (first name). That gives you an easy overview what's missing and which of those packages are yours. It's not a very long list, actually. It would be very nice if you could have a look if some of your packages are still missing and build them as time permits. Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind), just say the word and I remove them from the list. The list is also available online at http://cygwin.com/cygwin-64bit-missing. I'll keep it up-to-date as new packages arrive. ORPHANED aewm++ aewm++-goodies brltty bsdiff bsflite ccdoc cramfs distcc editrights ioperm jgraph libusb-1.0 libusb-win32 lyx mtd naim nfs-server ninvaders pal par pdksh pinfo ping tnef whois xgraph xmon Unknown maintainer perl-clone Aaron Schneider pv Achim Gratz ucl upx Andrew Schulman lablgtk2 lftp orpie ploticus sng unison Charles Wilson alternatives automake1.5 automake1.6 automake1.7 automake1.8 inetutils libAfterImage libassuan libgeotiff libksba libtirpc login mingw-libgcrypt mingw-libgpg-error mingw-xz nfrotz p7zip pinentry proj pth rpcgen rsh rxvt ssmtp sunrpc tack xerces-c xinetd xpm-nox xsri Chris January procps Chris Sutcliffe astyle hexedit libtorrent rtorrent wtf Christian Franke cdrkit ddrescue grub hdparm isomaster ncdu Christopher Faylor ccache ed mutt rpm time Corinna Vinschen swi-prolog Damien Doligez ocaml David Levine nmh David Rothenberger pdftk Dr. Volker Zell xemacs Eric Blake cppi patchutils xdelta Federico Hernandez task Jan Nieuwenhuizen lilypond Jari Aalto abook afio annoyance-filter antiword apng2gif apngasm apngdis apngopt apngtools arc arj aview bcrypt bmp2png bool boxes bvi cdargs cfourcc chkconfig corkscrew cscope ctorrent delta deroff dhttpd dog duff epstool fcrackzip fdupes figlet flip flog fossil geoip gif2apng git-oodiff greed httping httptunnel ifile ii indent integrit iprint iselect jlint joe kgb lcab links lv lzop mairix micro-httpd mmv most msmtp ncftp newmail nrss nttcp odt2txt ogmtools oodiff optipng outguess pax pngcheck pngcrush pngquant posh potrace pristine-tar pscan pstotext pwgen qiv qsf rats rc readpst renameutils renattach rtf2html-htdig rxp rzip sgrep shed sic since spamoracle splint steghide suck sudoku symlinks tig tinyirc tirc tnftp tree ttcp unace unalz unifdef unrtf untex vfu wcd wdiff wiggle wput xlhtml xloadimage xtail ytree zoo zsync Jason Tishler fetchmail procmail proftpd Jon Turney libxcwm xlaunch xtow xview Jon Y gendef libmangle lzip lziprecover Jorge Díaz varnish Klaus Grue logiweb Kostya Altukhov connect-proxy gaffitter irssi pure-ftpd Marco Atzeri netcdf octave-forge texmacs Mark O'Keefe amanda Michael McTernan mscgen Mike White iperf Nathan Thern chicken Peter A. Castro suite3270 Peter Li gnucap pbzip2 Pierre A. Humblet cron dmalloc exim Reini Urban catdoc clamav clisp ctris fcgi ffcall libsigsegv libtextcat mathomatic mosh parrot perl-io-tty perl-libwin32 perl-win32-gui protobuf rakudo scsh tesseract-ocr Roland Cassard xclip Ross Smith II email Serge Lamikhov-Center elfio Steven Monai maradns md5deep ucspi-tcp Stuart Caie cabextract Teun Burgers cgoban gnugo Thomas Wolff algol68g Yaakov S beforelight e2fsimage editres exif flexdll fvwm grace grandr gsm js185 libesmtp libmetalink lighttpd llvm mkcomposecache nspr nss odbc-psql python-twisted sessreg snownews xcb-util-renderutil xfindproxy xwinwm Yitzchak Scott-Thoennes fortune Yue Ren singular HTH, Corinna -- Corinna Vinschen Please, send mails
Re: Sorted list of packages missing in the 64 bit distro yet
On 8/1/2013 10:37 AM, Corinna Vinschen wrote: Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind) Given that they all had such extensive test suites, I thought it would be a useful smoke test to run them on cygwin64. So, I rebuilt and re-ran all of the test suites, on both cygwin32 and cygwin64, for all ELEVEN versions [1] of automake... 1.14 should finish in about seven more hours. [2] So...thanks, but... :-) As soon as the last test is finished, and I compose all of the announcement messages, I'll upload everything for both 32- and 64-. Should be sometime this evening or tomorrow morning. [1] 1.4p6, 1.5,1.6.3, 1.7.9, 1.8.5, 1.9.6, 1.10.3, 1.11.6, 1.12.6, 1.13.4, 1.14 not counting the automake wrapper (updated to -9, in support of am1.14), and the gcc-tools-epoch[1,2]-[autoconf,automake] packages, which are also ready for both 32- and 64-. [2] The good news is, other than the SIGQUIT thing reported earlier, behavior on 32- and 64- is identical, when you compensate for the fact that some tests are skipped because their prerequisites aren't present yet on 64-. I notice that older automakes now have more failures than they did back when originally built/tested (even on cygwin32); that appears to be due to changes in autoconf, libtool, and gettext which newer automakes have accommodated, but older ones have (obviously) not. The list is also available online at http://cygwin.com/cygwin-64bit-missing. I'll keep it up-to-date as new packages arrive. ORPHANED editrights Really? it's in the cygwin-apps repository; I thought *you* were the maintainer. Charles Wilson automake1.5 automake1.6 automake1.7 automake1.8 These are in progress... xpm-nox This is an obsolete (and marked so in its Category) backwards compatibility DLL (cygXpm-noX4.dll). It was replaced by libXpm-noX (libXpm-noX_4 contains cygXpm-noX_4.dll; note the extra underscore) in 2009. There has been a 64bit version of libXpm-noX up since 7/1/2013. At this point (seven years after last update, and four years since it was obsoleted) I think it's okay to simply delete the 32bit xpm-nox. There is nothing left that depends on it. Your call. alternatives inetutils libAfterImage libassuan libgeotiff libksba libtirpc login mingw-libgcrypt mingw-libgpg-error mingw-xz nfrotz p7zip pinentry proj pth rpcgen rsh rxvt ssmtp sunrpc tack xerces-c xinetd xsri ...and these aren't, yet. Sigh. There's also a number of packages that Yaakov built for 64 (ncurses, others; thanks, Yaakov!) that I need to pull over to my repo -- simply so I'll be prepared to continue maintenance in the future. I might also, at that time, update them as well. I've got a big ol' list. -- Chuck
Re: Sorted list of packages missing in the 64 bit distro yet
Charles Wilson wrote: ssmtp I built this for 64-bit myself last weekend and had to include the attached patch to avoid a SEGV, FWIW. -- David Rothenberger daver...@acm.org 3rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped include-libgen.patch Description: application/itunes-itlp
Re: Sorted list of packages missing in the 64 bit distro yet
On Aug 1 11:32, Charles Wilson wrote: On 8/1/2013 10:37 AM, Corinna Vinschen wrote: Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind) Given that they all had such extensive test suites, I thought it would be a useful smoke test to run them on cygwin64. So, I rebuilt and re-ran all of the test suites, on both cygwin32 and cygwin64, for all ELEVEN versions [1] of automake... 1.14 should finish in about seven more hours. [2] So...thanks, but... :-) As soon as the last test is finished, and I compose all of the announcement messages, I'll upload everything for both 32- and 64-. Should be sometime this evening or tomorrow morning. Cool. The list is also available online at http://cygwin.com/cygwin-64bit-missing. I'll keep it up-to-date as new packages arrive. ORPHANED editrights Really? it's in the cygwin-apps repository; I thought *you* were the maintainer. That's a mistake, thanks for catching. I added editrights to the 64 bit distro long ago, but officially the package is in orphaned by Jari Aalto stage. I'll change that in cygwin-pkg-maint and enter myself as maintainer. xpm-nox This is an obsolete (and marked so in its Category) backwards compatibility DLL (cygXpm-noX4.dll). That wasn't noted in cygwin-pkg-config. 7/1/2013. At this point (seven years after last update, and four years since it was obsoleted) I think it's okay to simply delete the 32bit xpm-nox. There is nothing left that depends on it. Done. ...and these aren't, yet. Sigh. There's also a number of packages that Yaakov built for 64 (ncurses, others; thanks, Yaakov!) that I need to pull over to my repo -- simply so I'll be prepared to continue maintenance in the future. I might also, at that time, update them as well. I've got a big ol' list. :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64-bit Request for Testing] cppcheck-1.60.1-1
On 2013-08-01 08:53, Chris Sutcliffe wrote: On 1 August 2013 08:04, Corinna Vinschen wrote: On Aug 1 07:36, Chris Sutcliffe wrote: One thing I noticed is that cygport listed cygwin64-gcc-core as a dependency for cppcheck. Will this cause an issue when installed on 64-bit Cygwin? This looks wrong. I removed this dependency manually for now. The correct dependency is libgcc1, and the same is true if cygwin32-gcc-core shows up in a 64-32 scenario. Thanks, I'll clean up my local copy as well. Yaakov, I'm assuming cygport is picking this up automatically, is there anyway it can be skipped, or is it something I'll need to keep an eye on going forward? You should *always* look at the dependencies and make sure they make sense, that's why they're shown when generated. In the case of libgcc1, I'm afraid you'll need to edit this manually until I figure out a workaround. Yaakov
Re: Sorted list of packages missing in the 64 bit distro yet
Il 8/1/2013 4:37 PM, Corinna Vinschen ha scritto: Hi maintainers, Marco Atzeri netcdf octave-forge texmacs texmacs is up HTH, Corinna
Re: Sorted list of packages missing in the 64 bit distro yet
On Aug 1 18:48, marco atzeri wrote: Il 8/1/2013 4:37 PM, Corinna Vinschen ha scritto: Hi maintainers, Marco Atzeri netcdf octave-forge texmacs texmacs is up Thanks! Dropped from cygwin-64bit-missing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Sorted list of packages missing in the 64 bit distro yet
On 2013-08-01 09:37, Corinna Vinschen wrote: from the list Yaakov generated today, I created another list of missing packages sorted by maintainer (first name). That gives you an easy overview what's missing and which of those packages are yours. It's not a very long list, actually. It would be very nice if you could have a look if some of your packages are still missing and build them as time permits. Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind), just say the word and I remove them from the list. The list is also available online at http://cygwin.com/cygwin-64bit-missing. I'll keep it up-to-date as new packages arrive. ORPHANED [snip] pdksh This is actually an obsolete package that I missed; its replacement is mksh. Unknown maintainer perl-clone That's mine, as a prerequisite of perl-DBI, and it's now in my upload queue. Damien Doligez ocaml Ping? David Rothenberger pdftk This requires gcc-java. Yaakov
Re: building Perl module DBD-ODBC-4.3 under 64-bit cygwin
On 2013-08-01 07:57, Simon Barnes wrote: I'm having difficulty with this and would appreciate any suggestions. It does build under 32-bit cygwin. Not really. The included makefile tries to force Cygwin to use ODBC32, where we use iODBC; the conflicts between the two is what cause this error. A patch to correctly build DBD::ODBC is in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/perl-DBD-ODBC;a=tree A binary perl-DBD-ODBC is also available in the Ports repo. Yaakov
[64-bit Request for Testing] astyle-2.03-1
I've created a 64-bit version of astyle via a cross-compile and I would appreciate it if someone could give it a spin: --- wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-2.03-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-2.03-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-debuginfo/astyle-debuginfo-2.03-1.tar.bz2 --- It compile cleanly, so hopefully all is good. Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: Sorted list of packages missing in the 64 bit distro yet
On Aug 1 12:17, Yaakov (Cygwin/X) wrote: On 2013-08-01 09:37, Corinna Vinschen wrote: from the list Yaakov generated today, I created another list of missing packages sorted by maintainer (first name). That gives you an easy overview what's missing and which of those packages are yours. It's not a very long list, actually. It would be very nice if you could have a look if some of your packages are still missing and build them as time permits. Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind), just say the word and I remove them from the list. The list is also available online at http://cygwin.com/cygwin-64bit-missing. I'll keep it up-to-date as new packages arrive. ORPHANED [snip] pdksh This is actually an obsolete package that I missed; its replacement is mksh. Unknown maintainer perl-clone That's mine, as a prerequisite of perl-DBI, and it's now in my upload queue. Both fixed in cygwin-64bit-missing and cygwin-pkg-maint. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[64-bit Request for Testing] hexedit-1.2.13-1
I've created a 64-bit version of hexedit via a cross-compile and I would appreciate it if someone could give it a spin: --- wget -x -nH --cut-dirs=3 \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/setup.hint \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-1.2.13-1.tar.bz2 \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-1.2.13-1-src.tar.bz2 \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-debuginfo/setup.hint \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-debuginfo/hexedit-debuginfo-1.2.13-1.tar.bz2 --- It compiled cleanly, so hopefully all is good. Thanks, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: [64-bit Request for Testing] astyle-2.03-1
On Aug 1 13:51, Chris Sutcliffe wrote: I've created a 64-bit version of astyle via a cross-compile and I would appreciate it if someone could give it a spin: --- wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-2.03-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-2.03-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin64/astyle/astyle-debuginfo/astyle-debuginfo-2.03-1.tar.bz2 --- It compile cleanly, so hopefully all is good. Any chance to provide an STC for non-users? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64-bit Request for Testing] astyle-2.03-1
On 1 August 2013 13:53, Corinna Vinschen wrote:
On Aug 1 13:51, Chris Sutcliffe wrote:
I've created a 64-bit version of astyle via a cross-compile and I
would appreciate it if someone could give it a spin:
Any chance to provide an STC for non-users?
Using the attached files:
astyle --style=gnu ./test.c
test.c should match test.c.out and a test.c.orig file should be generated.
Thanks!
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
#include stdio.h
void main(void)
{
printf(hi\n);
}
test.c.out
Description: Binary data
Re: [64-bit Request for Testing] astyle-2.03-1
On Aug 1 14:05, Chris Sutcliffe wrote: On 1 August 2013 13:53, Corinna Vinschen wrote: On Aug 1 13:51, Chris Sutcliffe wrote: I've created a 64-bit version of astyle via a cross-compile and I would appreciate it if someone could give it a spin: Any chance to provide an STC for non-users? Using the attached files: astyle --style=gnu ./test.c test.c should match test.c.out and a test.c.orig file should be generated. Looks good, uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64-bit Request for Testing] hexedit-1.2.13-1
On Aug 1 13:53, Chris Sutcliffe wrote: I've created a 64-bit version of hexedit via a cross-compile and I would appreciate it if someone could give it a spin: --- wget -x -nH --cut-dirs=3 \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/setup.hint \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-1.2.13-1.tar.bz2 \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-1.2.13-1-src.tar.bz2 \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-debuginfo/setup.hint \ http://dl.dropboxusercontent.com/u/5530441/cygwin64/hexedit/hexedit-debuginfo/hexedit-debuginfo-1.2.13-1.tar.bz2 --- It compiled cleanly, so hopefully all is good. It is. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[64-bit] nmh-1.5-2
Please upload nmh-1.5-2 for 64-bit only: http://www.cs.wustl.edu/~levine/nmh/64bit/nmh-1.5-2-src.tar.bz2 http://www.cs.wustl.edu/~levine/nmh/64bit/nmh-1.5-2.tar.bz2 Thanks, David
Re: [64-bit] nmh-1.5-2
Il 8/1/2013 9:46 PM, David Levine ha scritto: Please upload nmh-1.5-2 for 64-bit only: http://www.cs.wustl.edu/~levine/nmh/64bit/nmh-1.5-2-src.tar.bz2 http://www.cs.wustl.edu/~levine/nmh/64bit/nmh-1.5-2.tar.bz2 Thanks, David setup.hint ?
[RFU] smartmontools-6.2-1
wget -e robots=off -np -nH --cut-dirs=1 -R'index.html*' -r \ http://franke.dvrdns.org/cygwin/x86/release/smartmontools \ http://franke.dvrdns.org/cygwin/x86_64/release/smartmontools Please remove 6.0-1. Christian
Re: [64-bit] nmh-1.5-2
Il 8/1/2013 9:46 PM, David Levine ha scritto: Please upload nmh-1.5-2 for 64-bit only: http://www.cs.wustl.edu/~levine/nmh/64bit/nmh-1.5-2-src.tar.bz2 http://www.cs.wustl.edu/~levine/nmh/64bit/nmh-1.5-2.tar.bz2 setup.hint ? It's in the directory above, I just added symlinks. David
Re: Sorted list of packages missing in the 64 bit distro yet
On 01/08/13 15:37, Corinna Vinschen wrote:
It would be very nice if you could have a look if some of your packages
are still missing and build them as time permits.
ORPHANED
ninvaders
Couldn't resist! Yours if you would like it:
# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/ninvaders/ninvaders-0.1.1-1-src.tar.bz2 \
${BASEURL}/ninvaders/ninvaders-0.1.1-1.tar.bz2 \
${BASEURL}/ninvaders/ninvaders-debuginfo/ninvaders-debuginfo-0.1.1-1.tar.bz2
\
${BASEURL}/ninvaders/ninvaders-debuginfo/setup.hint \
${BASEURL}/ninvaders/setup.hint
I started with the 32-bit source. This had an enormous sh script to
build and prepare the files for upload. I couldn't get this to work, so
I wrote a cygport file and used that instead. Some of the patches in the
32-bit version were a little bizarre; I carried across the ones that
made sense.
BTW, 'ninvaders -gpl' is supposed to show the text of the GPL. This is
broken in the existing 32-bit build, but I fixed it for the 64-bit build
above. Would you like me to roll a 32-bit build with the fix?
Cheers,
Dave.
Re: Cygwin 1.7.22 calls dumper when starting X
Charles Wilson wrote:
Is there a way to test run-2.0? What is the syntax to replace:
C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
Sure:
and how to replace
C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*};
XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null '
(which works fine with run-1.2!)
I have tried this:
$ cat /home/angelo/XWinServer.xml
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl
-multiwindow -clipboard -silent-dup-error 2/dev/null '/Arg
/Target
/Global
/Run2Config
with this target in the link (.lnk):
C:\cygwin-2\bin\run2.exe /home/angelo/XWinServer.xml
but it doesn't work...
Ciao,
Angelo.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin 1.7.22 calls dumper when starting X
On 8/1/2013 7:19 AM, Angelo Graziosi wrote:
Charles Wilson wrote:
Is there a way to test run-2.0? What is the syntax to replace:
C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe
Sure:
and how to replace
C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*};
XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null '
(which works fine with run-1.2!)
I have tried this:
$ cat /home/angelo/XWinServer.xml
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl
-multiwindow -clipboard -silent-dup-error 2/dev/null '/Arg
/Target
/Global
/Run2Config
with this target in the link (.lnk):
C:\cygwin-2\bin\run2.exe /home/angelo/XWinServer.xml
Two errors: the extra semicolon after XMLSchema-instance, and you do
need to use the 'amp;' construction instead of ''. See attached.
(I'm not sure why you need at all; unless it allows the bash shell to
exit, where otherwise it would hang around?)
FWIW, I've never tested run2 with multibyte UTF-8, so...you might be
better off setting the encoding to us-ascii.
--
Chuck
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2/dev/null amp;'/Arg
/Target
/Global
/Run2Config
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin
On 01/08/2013 01:55, Jeremy Elson wrote: I recently upgraded from the 32-bit to the 64-bit build of Cygwin 1.7.22 on Windows 8 x64. For the most part, everything works identically (except faster!). But I have noticed one problem: xterm no longer seems to respond to the magic escape codes that change its title. My shell uses this to update the title to reflect the current hostname and working directory, but after the upgrade all my xterms just have the same title: tcsh. I haven't seen any mention of this bug on the mailing lists. Is anyone else experiencing this problem? Thanks for pointing out this problem. It seems that x86_64 X server has a bug that meant that no window could change it's title after it started. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.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/
Re: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin
On Thu, Aug 1, 2013 at 10:28 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 01/08/2013 01:55, Jeremy Elson wrote: I recently upgraded from the 32-bit to the 64-bit build of Cygwin 1.7.22 on Windows 8 x64. For the most part, everything works identically (except faster!). But I have noticed one problem: xterm no longer seems to respond to the magic escape codes that change its title. My shell uses this to update the title to reflect the current hostname and working directory, but after the upgrade all my xterms just have the same title: tcsh. I haven't seen any mention of this bug on the mailing lists. Is anyone else experiencing this problem? Thanks for pointing out this problem. It seems that x86_64 X server has a bug that meant that no window could change it's title after it started. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2 Thanks for the very fast followup - yes, using the XWin binary below, my xterm can now set its title correctly! Thanks again, and regards, Jeremy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin 1.7.22 calls dumper when starting X
Charles Wilson wrote:
(I'm not sure why you need at all; unless it allows the bash shell to exit,
where otherwise it would hang around?)
Without the , there is an extra bash process running: I want just to
start XWin...
See attached.
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard
-silent-dup-error 2/dev/null amp;'/Arg
/Target
/Global
/Run2Config
I have copy/pasted it, but it doesn't work (I have also tried with us-ascii)
If I add the debug options you suggested, I got
opt_loglevel: 9
opt_nogui : 0
opt_notty : 1
opt_timeout : 0.50
opt_wait: 0
opt_force : auto
(run2_xml_stardocument) ctx=0x22aa8c
(run2_xml_enddocument) ctx=0x22aa8c
/home/angelo/XWinServer.xml: validation generated an internal error
There was an error parsing XWinServer.xml
exit status 1
Ciao,
Angelo.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin 1.7.22 calls dumper when starting X
See below...
On 8/1/2013 2:33 PM, Angelo Graziosi wrote:
Charles Wilson wrote:
(I'm not sure why you need at all; unless it allows the bash shell to
exit, where otherwise it would hang around?)
Without the , there is an extra bash process running: I want just to
start XWin...
See attached.
?xml version=1.0 encoding=UTF-8?
Run2Config
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
The semicolon at the end of the above line is a syntax error. You need to
remove it.
xsi:noNamespaceSchemaLocation=run2.xsd
SelfOptions /
Global
Environment /
Target filename=/usr/bin/bash.exe startin=/usr/bin
Arg-l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow
-clipboard -silent-dup-error 2/dev/null amp;'/Arg
/Target
/Global
/Run2Config
I have copy/pasted it, but it doesn't work (I have also tried with us-ascii)
If I add the debug options you suggested, I got
opt_loglevel: 9
opt_nogui : 0
opt_notty : 1
opt_timeout : 0.50
opt_wait: 0
opt_force : auto
(run2_xml_stardocument) ctx=0x22aa8c
(run2_xml_enddocument) ctx=0x22aa8c
/home/angelo/XWinServer.xml: validation generated an internal error
There was an error parsing XWinServer.xml
exit status 1
Ciao,
Angelo.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Rcpp installation fails on Cygwin: Rcpp::Timer not supported by your OS.
Thanks Yaakov, That looks exactly like what I need. May I ask how would I go about patching and installing it on my system? Cheers, On 31 July 2013 19:42, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: On 2013-07-31 12:37, Enrico Ferrero wrote: When trying to install your Rcpp R package from CRAN on Cygwin, compilation aborts with the following error: Timer.cpp:35:6: error: #error Rcpp::Timer not supported by your OS. Such an error means that the code needs to be patched to select (or add) a code block specific to that platform. A patch for Cygwin can be found in Ports git: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/R-Rcpp;a=tree Specifically for Cygwin, based on my limited understanding of Rcpp, it would appear that libRcpp.dll (the library, not the Rcpp.dll module) should be moved to $PATH, and a symlink .dll.a put in its place, for the benefit of other modules which would use this library. The cygport(5) found in the aforementioned repo handles that for you. Yaakov -- 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 -- Enrico Ferrero PhD Student Steve Russell Lab - Department of Genetics FlyChip - Cambridge Systems Biology Centre University of Cambridge e.ferr...@gen.cam.ac.uk http://flypress.gen.cam.ac.uk/ -- 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: Rcpp installation fails on Cygwin: Rcpp::Timer not supported by your OS.
On 2013-08-01 02:46, Enrico Ferrero wrote: Thanks Yaakov, That looks exactly like what I need. May I ask how would I go about patching and installing it on my system? 1) Manually: wget http://cran.r-project.org/src/contrib/Rcpp_0.10.4.tar.gz wget -O 0.10.4-cygwin.patch 'http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/R-Rcpp;a=blob_plain;f=0.10.4-cygwin.patch;hb=HEAD' tar axf Rcpp_0.10.4.tar.gz pushd Rcpp patch -p2 ../0.10.4-cygwin.patch popd R CMD INSTALL ./Rcpp mv /usr/lib/R/site-library/Rcpp/lib/libRcpp.dll /usr/bin/ ln -s /usr/bin/libRcpp.dll /usr/lib/R/site-library/Rcpp/lib/libRcpp.dll.a 2) Install cygport and git (and their prereqs), then: git clone git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/R-Rcpp cd R-Rcpp cygport R-Rcpp.cygport fetch prep build install package tar axf R-Rcpp-0.10.4-1/dist/R-Rcpp/R-Rcpp-0.10.4-1.tar.bz2 -C / git clean -dfq Yaakov -- 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: possible bug in 1.7.22-1 core DLLs
Greetings, starlight.201...@binnacle.cx! Some people like myself cannot abide subscribing to firehose mailing lists and prefer to view discussion threads with a browser. It does not mean contributors, direct or indirect, are any of value. Even if I were a direct contributor monitoring it closely, I would /dev/null the list and browse it. But it do mean that you break threading with your replies, making is hard to read archives after your bursts. -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.08.2013, 13:37 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
make-3.82.90-1-use-spawn-on-cygwin.diff
Hello,
Only very recently did i discover Pavel's patch on make
(see http://lists.gnu.org/archive/html/bug-make/2013-07/msg00019.html)
and applied it on top of make-3.99.90 (see alpha.gnu.org) with happy
results on many (about 100) public packages (including gcc, xerces-c,
coreutils etc.) and also packages from mine.
However, it fails to build cygwin-20130731 (last snapshot), although
the regular make-3.99.90 compiles this snapshot gracefully. I also
tried with the genuine make-3.82.90-1 with the same results: no problem
with the regular make-3.82.90-1, error with
the patched one. Nothing very new: the cygwin-20130707 snapshot fails
exactly the same.
The errors i obtain are as follows:
/tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 2:
use: command not found
/tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 3:
use: command not found
/tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: c++wrap:
line 4: syntax error near unexpected token `('
/tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: c++wrap:
line 4: `my $pgm = basename($0);'
while compiling (it's the first time that c++wrap is used):
c++wrap -O2 -g -fno-rtti -fno-exceptions -Wall -Wstrict-aliasing
-Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD
-Werror -fmerge-constants -ftracer -c -o _cygwin_crt0_common.o
/tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/cygwin/lib/_cygwin_crt0_common.cc
/tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/cygwin/../Makefile.common:43:
recipe for target `_cygwin_crt0_common.o' failed
I've also obtained something like: c++wrap not found
but i can't remember under which circumstances, but i'm sure that it
was
with the patch embedded.
I'm puzzled because some people (e.g. see
http://lists.gnu.org/archive/html/bug-make/2013-07/msg00023.html)
report
very positively about this patch.
Did I do something wrong (apart perhaps posting to the wrong list)?
Regards,
Denis Excoffier.
--
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
run2 operation
Re: un2 0.4.2 $ checkX --verbose checkX Info: Unspecified X display (check --display in xml SelfOptions or in cmdline; also check $DISPLAY environment variable). But, Xwindows is running, and was started from this terminal sith startx Shouldn't it be detected and the DISPLAY valued returned so that I could set the DISPLAY variable for this mintty windows as well? When I invoke run2 (from a shortcut with the example .xml file) it also start a mintty terminal window, but I want it to start an XWindow or at the least use the currntly running X server. The running server is not detected to the xml's GDI section of the xml is used. checkX is very good, but I wish it would detect a currently running X server and report it'S DISPLAY value. I have just started with run2, so I'm not privy to a lot of it and not xml savy yet. Any advice would be greatly appreciated. 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
building Perl module DBD-ODBC-4.3 under 64-bit cygwin
I'm having difficulty with this and would appreciate any suggestions. It does build under 32-bit cygwin. Thanks Simon cygwin perl Makefile.PL ** Remember to actually *READ* the README file! And re-read it if you have any problems. ** OSNAME: cygwin LANG: ODBCHOME: /usr LD_LIBRARY_PATH: DBROOT: WINDIR: C:\Windows II_SYSTEM: Perl: 5.014004 ExtUtils::MakeMaker: 6.57_05 Command line options: u! = undef w! = undef e! = undef g! = 0 x! = undef o=s = You are using a Perl configured with threading enabled. Please read the warnings in DBI about this. You should also be aware that on non-Windows platforms ODBC drivers come in two forms, thread-safe and non-thread-safe drivers and you may need to make sure you are using the right one. Press return to continue... Using ODBCHOME /usr Looking for iODBC libs in /usr/lib Found iODBC libs /usr/lib/libiodbc.dll.a,/usr/lib/libiodbcinst.dll.a in /usr/lib This looks like a iodbc type of driver manager. Warning: LD_LIBRARY_PATH doesn't include /usr/lib Checking if your kit is complete... Looks good Using DBI 1.623 (for perl 5.014004 on cygwin-thread-multi) installed in /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads/auto/DBI/ Using DBI 1.623 (for perl 5.014004 on cygwin-thread-multi) installed in /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads/auto/DBI/ Writing Makefile for DBD::ODBC Writing MYMETA.yml Warning: not all required environment variables are set. Warning: Will not be able to run tests as you have not defined all of DBI_DSN, DBI_USER and DBI_PASS environment variables. cygwin make cp Changes blib/lib/DBD/ODBC/Changes.pm cp FAQ blib/lib/DBD/ODBC/FAQ.pm cp TO_DO blib/lib/DBD/ODBC/TO_DO.pm cp ODBC.pm blib/lib/DBD/ODBC.pm gcc -c -DWITH_UNICODE -I/usr/include -I. -I/usr/include/w32api -I/usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads/auto/DBI -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -fstack-protector -DUSEIMPORTLIB -O3-DVERSION=\1.43\ -DXS_VERSION=\1.43\ -I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE -DWITH_UNICODE -I/usr/include ConvertUTF.c /usr/bin/perl.exe -p -e s/~DRIVER~/ODBC/g /usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads/auto/DBI/Driver.xst ODBC.xsi /usr/bin/perl.exe /usr/lib/perl5/5.14/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.14/ExtUtils/typemap ODBC.xs ODBC.xsc mv ODBC.xsc ODBC.c Warning: duplicate function definition 'data_sources' detected in ODBC.xs, line 482 gcc -c -DWITH_UNICODE -I/usr/include -I. -I/usr/include/w32api -I/usr/lib/perl5/vendor_perl/5.14/x86_64-cygwin-threads/auto/DBI -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -fstack-protector -DUSEIMPORTLIB -O3-DVERSION=\1.43\ -DXS_VERSION=\1.43\ -I/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE -DWITH_UNICODE -I/usr/include ODBC.c In file included from /usr/local/include/sql.h:19:0, from dbdodbc.h:7, from ODBC.h:8, from ODBC.xs:1: /usr/local/include/sqltypes.h:261:33: error: conflicting types for 'ULONG' typedef unsigned long ULONG; ^ In file included from /usr/include/w32api/windows.h:69:0, from dbdodbc.h:6, from ODBC.h:8, from ODBC.xs:1: /usr/include/w32api/windef.h:25:27: note: previous declaration of 'ULONG' was here typedef unsigned __LONG32 ULONG; ^ Makefile:390: recipe for target `ODBC.o' failed make: *** [ODBC.o] Error 1 cygwin uname -a CYGWIN_NT-6.1 SLB-70DFXN1 1.7.22(0.268/5/3) 2013-07-22 17:06 x86_64 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
RE: make-3.82.90-1-use-spawn-on-cygwin.diff
Hello! The errors i obtain are as follows: /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 2: use: command not found /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 3: use: command not found Yesterday i have successfully compiled CVS version of cygwin. Your symptoms looks like another problem, which i attempted to address by another patch, posted alongside this one (no-dos-paths-on-cygwin). The problem is by default make's configure thinks that it should use DOS-style paths by default. Since Cygwin by itself is a POSIX environment, which uses POSIX paths, this screws up badly in functions which deal with absolute paths. You can find the detailed description in this message: http://lists.gnu.org/archive/html/bug-make/2013-07/msg00038.html . Perhaps you (and someone else ? Corinna ? ) can join the discussion and help me to convince GNU people that these modifications are good and safe. You can either apply this patch before running configure (and don't forget to recreate it with autoconf, of course), or bypass the check using config.cache trick: --- cut --- echo ac_cv_dos_paths=no config.cache ./configure --cache-file=config.cache --- cut --- Actually i already tried to post this patch here some time ago, here is the thread: http://cygwin.com/ml/cygwin/2013-01/msg00113.html . For some reason those days back my attempts to send a patch were rejected from both addresses (work and home), so this ended up in a private discussion with Reini and Cristopher (IIRC). Someone of them told me that Cygwin's policy regarding make is to send all modifications upstream, so this time i tried directly on GNU mailing list. Of course i won't subject if the patch is accepted as part of Cygwin package. I'm just not very fond of rebuilding tools manually after every update. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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: run2 operation
On 8/1/2013 8:40 AM, wynfi...@gmail.com wrote:
Re: un2 0.4.2
$ checkX --verbose
checkX Info: Unspecified X display (check --display in xml
SelfOptions or in cmdline; also check $DISPLAY environment
variable).
But, Xwindows is running, and was started from this terminal sith
startx
Shouldn't it be detected and the DISPLAY valued returned so that I
could set the DISPLAY variable for this mintty windows as well?
No, that's not what checkX is for. You have to tell IT where you think
the X server is running, and it will tell you if it can contact a server
there. So:
$ checkX --display=127.0.0.1:0.0
[exits with status value 0 or 1]
Really, checkX is just a testing tool, that shares/exercises a lot of
the same under-the-hood code as run2. It's not really of that much use,
except *perhaps* as below.
When I invoke run2 (from a shortcut with the example .xml file) it
also start a mintty terminal window, but I want it to start an
XWindow or at the least use the currntly running X server.
Mintty is not an X program. I'm not sure what you are trying to
accomplish, except perhaps to arrange that *within* the mintty/bash
session, $DISPLAY is set correctly so that you can launch programs that
DO need X successfully?
The running server is not detected to the xml's GDI section of the
xml is used.
Right, if you don't tell it which display to contact, it doesn't guess.
You don't really want your GnuCash session showing up on somebody else's
XWindow display do you?
checkX is very good, but I wish it would detect a currently running X
server and report it'S DISPLAY value.
And how do you suggest it do that? Poll every reachable machine on the
local network using arp, extract the IP addrs, then ask each one if they
have a display on :0, :1, .. :99, and repeat?
I have just started with run2, so I'm not privy to a lot of it and
not xml savy yet.
Any advice would be greatly appreciated.
Read /usr/share/doc/run2/*
Something like this .sh script might do what you want...but you'd
probably want to launch it using a run2.xml GlobalTarget/ (or plain
old run.exe).
== snip ===
#!/bin/sh
export DISPLAY=127.0.0.1:0.0
start_XWin()
{
# Cleanup from last run.
rm -rf /tmp/.X11-unix
XWin -multiwindow -clipboard -silent-dup-error 2/dev/null
}
/usr/bin/checkX || start_XWin
while ! /usr/bin/checkX
do
## printf waiting for xserver to start\n
sleep 1
done
sleep 1
/usr/bin/urxvt-X
== snip ===
But that really does nothing, that 'startxwin.exe' and ~/.startxwinrc
already do better.
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: make-3.82.90-1-use-spawn-on-cygwin.diff
i won't subject if the patch is accepted as part of Cygwin package. I'm just not very fond of rebuilding tools manually after every update. Ooops, i wanted to say won't object. I. e. won't mind. :) Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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: building Perl module DBD-ODBC-4.3 under 64-bit cygwin
On Aug 1 12:57, Simon Barnes wrote: I'm having difficulty with this and would appreciate any suggestions. It does build under 32-bit cygwin. That's a good place to point to my extended how to port to 64 bit FAQ, starting here: http://cygwin.com/faq/faq.html#faq.programming.64bitporting Please read this first. Basically, what you see here... /usr/local/include/sqltypes.h:261:33: error: conflicting types for 'ULONG' typedef unsigned long ULONG; ^ In file included from /usr/include/w32api/windows.h:69:0, from dbdodbc.h:6, from ODBC.h:8, from ODBC.xs:1: /usr/include/w32api/windef.h:25:27: note: previous declaration of 'ULONG' was here typedef unsigned __LONG32 ULONG; ^ Makefile:390: recipe for target `ODBC.o' failed ...is a typical type conflict. ULONG is a Windows type defined as unsigned long in the Win32 API. The Win32 data model is LLP64, so unsigned long is 4 bytes. However, Cygwin is LP64, so unsigned long is 8 bytes. Therefore the `typedef unsigned long ULONG;' is wrong for 64 bit. Either drop the definition entirely, or redefine it matching the data model: #ifdef __LP64__ typedef unsigned int ULONG; #else typedef unsigned long ULONG; #endif HTH, 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: make-3.82.90-1-use-spawn-on-cygwin.diff
On Thu, Aug 01, 2013 at 05:39:22PM +0400, Pavel Fedin wrote: i won't subject if the patch is accepted as part of Cygwin package. I'm just not very fond of rebuilding tools manually after every update. Ooops, i wanted to say won't object. I. e. won't mind. :) You don't have to rebuild packages after every cygwin DLL update. 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: possible bug in 1.7.22-1 core DLLs
On Thu, Aug 01, 2013 at 01:38:07PM +0400, Andrey Repin wrote: Greetings, starlight.2013z3! Some people like myself cannot abide subscribing to firehose mailing lists and prefer to view discussion threads with a browser. It does not mean contributors, direct or indirect, are any of value. Even if I were a direct contributor monitoring it closely, I would /dev/null the list and browse it. But it do mean that you break threading with your replies, making is hard to read archives after your bursts. The other problem is that he forwarded someone's private (very reasonable) email to the cygwin list because he probably didn't realize that it was a private correspondence. That is a breach of netiquette. Also: http://xkcd.com/357/ 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: make-3.82.90-1-use-spawn-on-cygwin.diff
On 2013-08-01 15:09, Pavel Fedin wrote: Hello! The errors i obtain are as follows: /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 2: use: command not found /tmp/lcl/tmp/cygwin/cygwin-snapshot-20130731-1/winsup/c++wrap: line 3: use: command not found Yesterday i have successfully compiled CVS version of cygwin. Your symptoms looks like another problem, which i attempted to address by another patch, posted alongside this one (no-dos-paths-on-cygwin). The problem is by default make's configure thinks that it should use DOS-style paths by default. Since Cygwin by itself is a POSIX environment, which uses POSIX paths, this screws up badly in functions which deal with absolute paths. You can find the detailed description in this message: http://lists.gnu.org/archive/html/bug-make/2013-07/msg00038.html . Perhaps you (and someone else ? Corinna ? ) can join the discussion and help me to convince GNU people that these modifications are good and safe. You can either apply this patch before running configure (and don't forget to recreate it with autoconf, of course), or bypass the check using config.cache trick: --- cut --- echo ac_cv_dos_paths=no config.cache ./configure --cache-file=config.cache --- cut --- I did sed -i -e 's/__CYGWIN__/__NOEXIST20130801__/' make-3.99.90/configure as suggested in http://lists.gnu.org/archive/html/bug-make/2013-07/msg00020.html with no improvement for the compilation of cygwin-20130731 (same error messages). Perhaps i should try with make-3.82.90-1... By the way, where are the DOS paths when we talk about c++wrap? Denis Excoffier. -- 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: building Perl module DBD-ODBC-4.3 under 64-bit cygwin
On Aug 1 16:02, Corinna Vinschen wrote: On Aug 1 12:57, Simon Barnes wrote: I'm having difficulty with this and would appreciate any suggestions. It does build under 32-bit cygwin. That's a good place to point to my extended how to port to 64 bit FAQ, starting here: http://cygwin.com/faq/faq.html#faq.programming.64bitporting Please read this first. Basically, what you see here... /usr/local/include/sqltypes.h:261:33: error: conflicting types for 'ULONG' typedef unsigned long ULONG; ^ In file included from /usr/include/w32api/windows.h:69:0, from dbdodbc.h:6, from ODBC.h:8, from ODBC.xs:1: /usr/include/w32api/windef.h:25:27: note: previous declaration of 'ULONG' was here typedef unsigned __LONG32 ULONG; ^ Makefile:390: recipe for target `ODBC.o' failed ...is a typical type conflict. ULONG is a Windows type defined as unsigned long in the Win32 API. The Win32 data model is LLP64, so unsigned long is 4 bytes. However, Cygwin is LP64, so unsigned long is 8 bytes. Therefore the `typedef unsigned long ULONG;' is wrong for 64 bit. Either drop the definition entirely, or redefine it matching the data model: #ifdef __LP64__ typedef unsigned int ULONG; #else typedef unsigned long ULONG; #endif Btw., that's what the __LONG32 macro in the mingw-w64 headers is for... 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: make-3.82.90-1-use-spawn-on-cygwin.diff
On 2013-08-01 17:09, Denis Excoffier wrote: I did sed -i -e 's/__CYGWIN__/__NOEXIST20130801__/' make-3.99.90/configure as suggested in http://lists.gnu.org/archive/html/bug-make/2013-07/msg00020.html with no improvement for the compilation of cygwin-20130731 (same error messages). Perhaps i should try with make-3.82.90-1... Done. No change. Denis Excoffier. -- 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] [New 64-bit] cppcheck-1.60.1-1
The 64-bit version 1.60.1-1 of cppcheck has been uploaded. cppcheck is a tool for static C/C++ code analysis. It tries to detect bugs that your C/C++ compiler doesn't see. The goal is no false positives. cppcheck is versatile. You can check non-standard code that includes various compiler extensions, inline assembly code, etc. For a list of changes see: http://sourceforge.net/p/cppcheck/news/2013/06/cppcheck-1601/ http://sourceforge.net/p/cppcheck/news/2013/06/cppcheck-160/ Note: As of this release a debuginfo package is also available. *** 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.comatcygwin.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. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: building Perl module DBD-ODBC-4.3 under 64-bit cygwin
On 2013-08-01 07:57, Simon Barnes wrote: I'm having difficulty with this and would appreciate any suggestions. It does build under 32-bit cygwin. Not really. The included makefile tries to force Cygwin to use ODBC32, where we use iODBC; the conflicts between the two is what cause this error. A patch to correctly build DBD::ODBC is in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/perl-DBD-ODBC;a=tree A binary perl-DBD-ODBC is also available in the Ports repo. Yaakov -- 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] [64-bit New] astyle-2.03-1
I've uploaded a 64-bit version astyle, 2.03-1, in keeping with the current upstream release. For a list of changes check out http://astyle.sourceforge.net/notes.html . *** 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.com at 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. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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] [64-bit New] hexedit-1.2.13-1
A 64-bit release of hexedit, 1.2.13-1, is now available. hexedit shows a file both in ASCII and in hexadecimal. The file can be a device as the file is read a piece at a time. You can modify the file and search through it. For a list of changes see below. *** 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.comatcygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. february 2013: - fix displaying sector number when above 2^31 - fix potential file descriptor leak (thanks to Rich Burridge) - add DESTDIR support to the makefiles - preprocessor flags should use CPPFLAGS, not CFLAGS - fix a small issue in mymemmem/mymemrmem when HAVE_MEMMEM/HAVE_MEMRMEM is not defined -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: pango1.0.sh exit code 1
Martin Baute wrote: The libpango1.0 postinstall script fails with exit code 1 Same here on a W7 box (cygwin32). Same workaround. Strangely, on XP it worked fine some time ago (probably in the 2009).. 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: pango1.0.sh exit code 1
On 2013-08-01, Angelo Graziosi wrote: Martin Baute wrote: The libpango1.0 postinstall script fails with exit code 1 Same here on a W7 box (cygwin32). Same workaround. Strangely, on XP it worked fine some time ago (probably in the 2009).. As I reported in an earlier thread (Recent Cygwin problems, June 21, 2013), I didn't see this message on XP until sometime in May or June of this year. Regards, Gary -- 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
setsockopt support for SO_RCVTIMEO
It appears Cygwin setsockopt doesn't do anything with the socket options SO_RCVTIMEO or SO_SNDTIMEO. Then I also found this: http://cygwin.com/ml/cygwin/2003-01/msg00833.html But those options work on Windows (Win7 to be precise). Has that always been the case or has Cygwin not caught up yet - IOW, is support possible/planned? 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: setsockopt support for SO_RCVTIMEO
On Thu, Aug 1, 2013 at 7:41 PM, Balaji Venkataraman wrote: It appears Cygwin setsockopt doesn't do anything with the socket options SO_RCVTIMEO or SO_SNDTIMEO. Then I also found this: http://cygwin.com/ml/cygwin/2003-01/msg00833.html But those options work on Windows (Win7 to be precise). Has that always been the case or has Cygwin not caught up yet - IOW, is support possible/planned? Thanks. I believe there was actually a discussion about this a few weeks back. http://cygwin.com/ml/cygwin/2013-07/msg00112.html Sean -- 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: 64-bit emacs crashes a lot
On 26/07/2013 11:32 PM, Ryan Johnson wrote: On 26/07/2013 10:50 PM, Ken Brown wrote: On 7/26/2013 8:32 PM, Ryan Johnson wrote: Hi all, Running 64-bit cygwin 1.7.22(0.268/5/3), with emacs-nox 24.3-4 inside mintty 1.2-beta1-1, I keep getting seg faults and Fatal error 6: Aborted It happens at strange times, invariably during I/O of some kind (either keyboard input or output from some compilation window); I don't get the impression it's fork-related. I don't know how to get a backtrace from emacs, given the way any exception or signal always loses the userland stack (suggestions welcome). Anyone else seeing this? This doesn't really answer your question since I don't use emacs-nox, but I've been running 64-bit emacs-X11 and finding it very stable. I typically keep it running for several days at a time. You say you don't know how to get a backtrace from emacs. I assume you've installed emacs-debuginfo and run emacs under gdb. Are you saying you can never get a backtrace after it crashes? I do have the emacs-debuginfo. I meant that the stack dump didn't have any emacs frames in it (they were all cygwin1.dll), and my experience with cygwin/gdb is that once you've taken a signal or exception you lose the cygwin stack and just see a bunch of threads mucking around in various low-level Windows dlls. I have tried attaching gdb to emacs and setting a breakpoint on abort(), but it didn't catch anything yet. I'm also hampered by gdb constantly getting confused, breaking partway into emacs, and having to detach/reattach it. I've started a new thread for that issue. Here's a new one... I started a compilation, but before it actually invoked the command it started pegging the CPU. After ^G^G^G, it crashed with the following: Auto-save? (y or n) y 0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: *** fatal error - Internal error: TP_NUM_W_BUFS too small 2268032 = 10. Hangup The stackdump has the following: usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exception.h:65 /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dcrt0.cc:1268 /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/dcrt0.cc:1277 /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/tls_pbuf.cc:53 /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/path.cc:614 /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/syscalls.cc:1894 001801130CB 023 000775DB65E /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/miscfuncs.cc:803 /usr/src/debug/emacs-24.3-4/src/alloc.c:2147 /usr/src/debug/emacs-24.3-4/src/fileio.c:5465 /usr/src/debug/emacs-24.3-4/src/keyboard.c:10755 /usr/src/debug/emacs-24.3-4/src/sysdep.c:1582 /usr/src/debug/cygwin-1.7.22-1/winsup/cygwin/exceptions.cc:1453 001801131E1 Thoughts? Ryan -- 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
[64-bit New] astyle-2.03-1
I've uploaded a 64-bit version astyle, 2.03-1, in keeping with the current upstream release. For a list of changes check out http://astyle.sourceforge.net/notes.html . *** 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.com at 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. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
[64-bit New] hexedit-1.2.13-1
A 64-bit release of hexedit, 1.2.13-1, is now available. hexedit shows a file both in ASCII and in hexadecimal. The file can be a device as the file is read a piece at a time. You can modify the file and search through it. For a list of changes see below. *** 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.comatcygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. february 2013: - fix displaying sector number when above 2^31 - fix potential file descriptor leak (thanks to Rich Burridge) - add DESTDIR support to the makefiles - preprocessor flags should use CPPFLAGS, not CFLAGS - fix a small issue in mymemmem/mymemrmem when HAVE_MEMMEM/HAVE_MEMRMEM is not defined -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
