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) 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 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
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 (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.comcygwin.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 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.comcygwin.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
Case sensitive filenames for non-NTFS filesystems
Hi, As per: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive Cygwin act on filenames on NTFS in with case preservation/sensitivity. As this was a feature configured in the Windows kernel, the pre-existing limitation whereby the same case sensitivity was not available for FAT32 was an understandable compromise. Unfortunately, in providing EXFAT, Microsoft has not seen fit to carry over the same handling in the kernel as it does in NTFS. In my opinion, the knock on limitation in Cygwin for FAT32 was easy to accept as it was quite inferior to NTFS. The limitation with EXFAT is a little difficult to accept, and this is the motive behind this email. I don't expect much interest in this suggestion, but make it here to at least bring awareness to the problem. Can I suggest that if it is a) feasible b) doable without too much added degradation in performance/complexity to the file handling code, that Cygwin add some limited support itself. I'm not talking about going back to something like the old managed mounts, but more to its replacement function. That being the same handling of special characters like :, |, etc that Cygwin employs. That is, the use of the special Unicode breakout character. It can be used when a name collision is detected (yes, detection code required. I don't know how costly that would be). eg. Hello and HELLO, would end up with something like (posix=0 still required on mount): * Hello is created first. No Hello file preexists. * attempt to create HELLO * detect file exists as Hello, but filename not equal on case * detect first case equal character is H. * Use Unicode breakout on H in HELLO. * Unfortunately, will need to recurse (expensive) and redo checks above (with breakout) I haven't completely thought this through. And as I typed the above, it sounds expensive. However, I'd love to hear opinion on this anyway. Is the trade-off large enough to fall back on the "just use NTFS" argument? -- Thanks, Shaddy -- 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
