[ANNOUNCEMENT] Updated: tinyxml2-2.2.0
Version 2.2.0-1 of tinyxml2 has been uploaded. DESCRIPTION === TinyXML-2 is a simple, small, efficient, C++ XML parser that can be easily integrated into other programs. It uses a Document Object Model (DOM), meaning the XML data is parsed into a C++ objects that can be browsed and manipulated, and then written to disk or another output stream. TinyXML-2 doesn't parse or use DTDs (Document Type Definitions) nor XSLs (eXtensible Stylesheet Language). TinyXML-2 uses a similar API to TinyXML-1, But the implementation of the parser was completely re-written to make it more appropriate for use in a game. It uses less memory, is faster, and uses far fewer memory allocations. HOMEPAGE http://www.grinninglizard.com/tinyxml2/ Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: cppcheck-1.67-1
Version 1.67-1 of cppcheck has been updated. RELEASE NOTES = http://sourceforge.net/p/cppcheck/news/2014/10/cppcheck-167/ CHANGE LOG == Changes from 1.66 to 1.67: General changes: - Library files have now a 'format' attribute. Format version 1 is assumed by default - Cppcheck does no longer abort checking if unhandled characters (Non-ASCII) are found New checks: - Check for unused return values - Detect shift by too many bits, signed integer overflow and dangerous sign conversion - Recommend usage of expm1(), log1p(), erfc() - Division by sizeof() as parameter to memset/memcpy/memmove/etc. as they expect a size in bytes - Several new va_arg related checks: -- Wrong parameter passed to va_start() -- Reference passed to va_start() -- Missing va_end() -- Using va_list before it is opened -- Subsequent calls to va_start/va_copy() - Initialization by itself in initializer list - Dead pointer usage when pointer alias local variable that has gone out of scope Improvements: - Support uniform initialization syntax (C++11) - Much improvements to value flow analysis - Improved AST creation (support placement new, C++-style casts, templates, operator new[], ...) - Improved lambda support - Support GCC extension attriute((used)) and MSVC extension __declspec(property) - Better support for static member variables, inherited variables and namespaces - Improved typedef support where multiple variables are declared at once - Avoid checking code multiple times by calculating a checksum. Duplicate preprocessor configurations are eliminated by this. - Support C++03/C 'auto' keyword Additionally, lots of false positives and bugs have been fixed and several existing checks have been improved. DESCRIPTION === Cppcheck is a static analysis tool for C/C++ code. Unlike C/C++ compilers and many other analysis tools it does not detect syntax errors in the code. Cppcheck primarily detects the types of bugs that the compilers normally do not detect. The goal is to detect only real errors in the code (i.e. have zero false positives). WEBSITE === http://cppcheck.sourceforge.net/ Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin.com/cgi-bin not found
On Oct 19 16:42, Steven Penny wrote:
> http://cygwin.com/cgi-bin was to my knowledge the only place you could find
> the
> source to such important files as "package-grep.cgi"
>
> http://cygwin.com/ml/cygwin/2014-06/msg00127.html
>
> However this and other pages found in Cygwin Robots have gone missing, notice
>
> curl -s cygwin.com/robots.txt |
> awk '$2 && !seen[$2]++ {print $2}' FS=/ |
> while read each
> do printf '%-12s' "$each"
> wget --spider --quiet cygwin.com/$each && echo GOOD || echo BAD
> done
>
> Yields this
>
> ml GOOD
> bugzillaGOOD
> cgi-bin BAD
> cgi BAD
> cgi2-binBAD
> packagesGOOD
> snapshots GOOD
> viewcvs GOOD
> viewvc GOOD
>
> What happened to these pages?
Removed at some point in the past. You referenced the correct path
yourself in the mail the above link points to ;)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpUcFXd0rRFs.pgp
Description: PGP signature
[ANNOUNCEMENT] Updated: nspr-4.10.6-1, nss-3.16.6-1
The following packages have been updated in the Cygwin distribution: *** libnspr4-4.10.6-1 *** libnspr-devel-4.10.6-1 *** nss-3.16.6-1 *** libnss3-3.16.6-1 *** libnss-devel-3.16.6-1 Netscape Portable Runtime (NSPR) provides a platform-neutral API for system-level and libc-like functions. Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. This is an update to the stable release branches, including a fix for CVE-2014-1568. -- 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] Updated: p11-kit-0.20.7-1
The following packages have been updated for the Cygwin distribution: * p11-kit-0.20.7-1 * p11-kit-trust-0.20.7-1 * libp11-kit0-0.20.7-1 * libp11-kit-devel-0.20.7-1 * libp11-kit-doc-0.20.7-1 p11-kit provides an API for loading and enumerating PKCS#11 modules. This is an update to the latest bugfix release for the 0.20 stable branch. -- 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] New: php-5.5.18-1
The following packages have been added to the Cygwin distribution: * php-5.5.18-1 * apache2-mod_php5-5.5.18-1 * php-bcmath-5.5.18-1 * php-bz2-5.5.18-1 * php-calendar-5.5.18-1 * php-ctype-5.5.18-1 * php-curl-5.5.18-1 * php-dba-5.5.18-1 * php-devel-5.5.18-1 * php-enchant-5.5.18-1 * php-exif-5.5.18-1 * php-fileinfo-5.5.18-1 * php-ftp-5.5.18-1 * php-gd-5.5.18-1 * php-gettext-5.5.18-1 * php-gmp-5.5.18-1 * php-iconv-5.5.18-1 * php-imap-5.5.18-1 * php-intl-5.5.18-1 * php-jsonc-1.3.5-1 * php-ldap-5.5.18-1 * php-mbstring-5.5.18-1 * php-mcrypt-5.5.18-1 * php-mssql-5.5.18-1 * php-mysql-5.5.18-1 * php-mysqli-5.5.18-1 * php-odbc-5.5.18-1 * php-opcache-5.5.18-1 * php-pdo_dblib-5.5.18-1 * php-pdo_mysql-5.5.18-1 * php-pdo_odbc-5.5.18-1 * php-pdo_sqlite-5.5.18-1 * php-pgsql-5.5.18-1 * php-phar-5.5.18-1 * php-posix-5.5.18-1 * php-pspell-5.5.18-1 * php-readline-5.5.18-1 * php-recode-5.5.18-1 * php-shmop-5.5.18-1 * php-simplexml-5.5.18-1 * php-soap-5.5.18-1 * php-sockets-5.5.18-1 * php-sqlite3-5.5.18-1 * php-sybase_ct-5.5.18-1 * php-sysvmsg-5.5.18-1 * php-sysvsem-5.5.18-1 * php-sysvshm-5.5.18-1 * php-tidy-5.5.18-1 * php-tokenizer-5.5.18-1 * php-wddx-5.5.18-1 * php-xmlreader-5.5.18-1 * php-xmlrpc-5.5.18-1 * php-xmlwriter-5.5.18-1 * php-xsl-5.5.18-1 * php-zip-5.5.18-1 * php-zlib-5.5.18-1 PHP (recursive acronym for 'PHP: Hypertext Preprocessor') is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. This release contains several bugfixes, including for CVE-2014-3668, CVE-2014-3669, and CVE-2014-3670. -- 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: gfortran and lapack problem
I compile it as gfortran MyTest.f90 -o MyTest -llapack -lblas. I don't get any errors (it says "compilation finished"), but the output file doesn't print anything (neither the strings, or the variable info). If I comment the "CALL DGESV" line, it does print everything (with info=0, of course). 32 bit or 64 bit Cygwin? Works for me, I get $ gfortran MyTest.f90 -o MyTest -llapack -lblas $ ./MyTest Printing the results 0 End printing So no "compilation finished" message. Might you have some other version of gfortran on your path? I believe cygcheck.out would list some of this information. Other things to check: which -a gfortran which -a cygblas-0.dll -- 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
installing mapserver in cygwin - regex.c problem
Hi, This is my first time installing mapserver in cygwin, but I'm a quite old user of both cygwin and mapserver (but still young =D ). The thing is that I'm getting a regex issue after doing cmake in the build directory inside the mapserver-6.4.1 directory (after doing tar -zxvf mapserver-6.4.1.tar.gz, etc, etc). My cygwin installation meets all the requirements afaik to build mapserver. I'm not sure, though, if regex.h is causing a problem. This is what I get after running cmake: -- Gery@gery /opt/mapserver/mapserver-6.4.1/build $ cmake .. -DWITH_CLIENT_WMS=1 -DWITH_CLIENT_WFS=1 -DWITH_SOS=1 -DWITH_KML=1 -DWITH_PHP=1 -DWITH_PERL=1 -DWITH_PYTHON=1 -DWITH_GD=1 -DWITH_GDAL=1 -DCMAKE_PREFIX_PATH="/opt/gdal/gdal-1.11.0" -DWITH_OGR=1 -DWITH_PROJ=1 -DCMAKE_LEGACY_CYGWIN_WIN32=1 -DWITH_ICONV=0 -DWITH_EXEMPI=0 -DWITH_MYSQL=0 -- Defining WIN32 under Cygwin due to CMAKE_LEGACY_CYGWIN_WIN32 -- /usr/include/php/main -- Found PHP5-Version 5.5.16 (using /usr/bin/php-config) -- * Summary of configured options for this build -- * Mandatory components -- * png: /usr/lib/libpng.dll.a -- * jpeg: /usr/lib/libjpeg.dll.a -- * freetype: /usr/lib/libfreetype.dll.a -- * Optional components -- * GDAL: /opt/gdal/gdal-1.11.0/libgdal.a -- * OGR: /opt/gdal/gdal-1.11.0/libgdal.a -- * GD: /usr/lib/libgd.dll.a -- * GIF: /usr/lib/libgif.dll.a -- * MYSQL: disabled -- * FRIBIDI: /usr/lib/libfribidi.dll.a -- * GIF: /usr/lib/libgif.dll.a -- * CAIRO: /usr/lib/libcairo.dll.a -- * SVGCAIRO: disabled -- * RSVG: disabled -- * CURL: /usr/lib/libcurl.dll.a -- * PROJ: /usr/lib/libproj.dll.a -- * LIBXML2: /usr/lib/libxml2.dll.a -- * POSTGIS: /usr/lib/libpq.a -- * GEOS: /usr/local/lib/libgeos_c.dll.a -- * FastCGI: /usr/lib/libfcgi.dll.a -- * Oracle Spatial: disabled -- * SDE: disabled -- * Exempi XMP: disabled -- * Optional features -- * WMS SERVER: ENABLED -- * WFS SERVER: ENABLED -- * WCS SERVER: ENABLED -- * SOS SERVER: ENABLED -- * WMS CLIENT: ENABLED -- * WFS CLIENT: ENABLED -- * ICONV: disabled -- * Thread-safety support: disabled -- * KML output: ENABLED -- * Z+M point coordinate support: disabled -- * XML Mapfile support: disabled -- * Mapscripts -- * Python: ENABLED -- * PHP: ENABLED -- * PERL: ENABLED -- * RUBY: disabled -- * JAVA: disabled -- * C&: disabled -- * Apache Module (Experimental): disabled -- -- Will install files to /usr/local -- Will install libraries to /usr/local/lib -- Configuring done CMake Error at CMakeLists.txt:233 (add_library): Cannot find source file: //regex.c Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx -- Build files have been written to: /opt/mapserver/mapserver-6.4.1/build Gery@gery /opt/mapserver/mapserver-6.4.1/build $ -- then it stops. make and make install do nothing, just a "stop" message appears: -- Gery@gery /opt/mapserver/mapserver-6.4.1/build $ make make: *** No targets specified and no makefile found. Stop. Gery@gery /opt/mapserver/mapserver-6.4.1/build $ make install make: *** No rule to make target 'install'. Stop. -- Any ideas? Thanks in advance, Gery -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: ca-certificates-2.1-1
The following package has been updated for the Cygwin distribution: * ca-certificates-2.1-1 ca-certificates contains the Certificate Authority root certificates needed for verifying SSL certificates. This release removes a number of certificates with weak keys as described in detail here: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.3_release_notes https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.4_release_notes -- 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: perl -d causes completion to fail
On Wed, Oct 15, 2014 at 03:08:42PM -0700, Andrew DeFaria wrote: > On 10/15/2014 2:30 PM, Andrew DeFaria wrote: > Adefaria-lt:ls /etc/bash_completion.d/perl > ls: cannot access /etc/bash_completion.d/perl: No such file or directory > Adefaria-lt:ls /usr/share/bash-completion/completions/perl > /usr/share/bash-completion/completions/perl > Adefaria-lt: > > I think you mean /usr/share/bash-completion/completions/perl... I > think the problem is that it's parsing the next token after -d and > -dt looking for :debugger and never things that maybe there's no > debugger name (see perldoc perldebug). Whatever you're using doesn't seem to be the Cygwin bash-completion package. Both x86 and x86_64 install /etc/bash_completion.d/perl: https://cygwin.com/packages/x86/bash-completion/bash-completion-1.3-1 https://cygwin.com/packages/x86_64/bash-completion/bash-completion-1.3-1 Before we go any further with anything else, I think your next step should probably be to install the Cygwin bash-completion package and check what the behaviour is there. -- 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: installing mapserver in cygwin - regex.c problem
I found the solution, it basically was to change this: -DCMAKE_LEGACY_CYGWIN_WIN32=1 to -DCMAKE_LEGACY_CYGWIN_WIN32=0 so, I used: cmake .. -DWITH_OGR=0 -DWITH_GDAL=0 -DWITH_WCS=0 -DWITH_WFS=0 -DCMAKE_LEGACY_CYGWIN_WIN32=0 and Mapserver compiled flawlessly. Thanks for all your comments and great interest!! :v > From: gameji...@hotmail.com > To: cygwin@cygwin.com > Subject: installing mapserver in cygwin - regex.c problem > Date: Mon, 20 Oct 2014 09:17:08 + > > Hi, > > This is my first time installing mapserver in cygwin, but I'm a quite old > user of both cygwin and mapserver (but still young =D ). > > The thing is that I'm getting a regex issue after doing cmake in the build > directory inside the mapserver-6.4.1 directory (after doing tar -zxvf > mapserver-6.4.1.tar.gz, etc, etc). My cygwin installation meets all the > requirements afaik to build mapserver. I'm not sure, though, if regex.h is > causing a problem. This is what I get after running cmake: > > -- > Gery@gery /opt/mapserver/mapserver-6.4.1/build > $ cmake .. -DWITH_CLIENT_WMS=1 -DWITH_CLIENT_WFS=1 -DWITH_SOS=1 -DWITH_KML=1 > -DWITH_PHP=1 -DWITH_PERL=1 -DWITH_PYTHON=1 -DWITH_GD=1 -DWITH_GDAL=1 > -DCMAKE_PREFIX_PATH="/opt/gdal/gdal-1.11.0" -DWITH_OGR=1 -DWITH_PROJ=1 > -DCMAKE_LEGACY_CYGWIN_WIN32=1 -DWITH_ICONV=0 -DWITH_EXEMPI=0 -DWITH_MYSQL=0 > -- Defining WIN32 under Cygwin due to CMAKE_LEGACY_CYGWIN_WIN32 > -- /usr/include/php/main > -- Found PHP5-Version 5.5.16 (using /usr/bin/php-config) > -- * Summary of configured options for this build > -- * Mandatory components > -- * png: /usr/lib/libpng.dll.a > -- * jpeg: /usr/lib/libjpeg.dll.a > -- * freetype: /usr/lib/libfreetype.dll.a > -- * Optional components > -- * GDAL: /opt/gdal/gdal-1.11.0/libgdal.a > -- * OGR: /opt/gdal/gdal-1.11.0/libgdal.a > -- * GD: /usr/lib/libgd.dll.a > -- * GIF: /usr/lib/libgif.dll.a > -- * MYSQL: disabled > -- * FRIBIDI: /usr/lib/libfribidi.dll.a > -- * GIF: /usr/lib/libgif.dll.a > -- * CAIRO: /usr/lib/libcairo.dll.a > -- * SVGCAIRO: disabled > -- * RSVG: disabled > -- * CURL: /usr/lib/libcurl.dll.a > -- * PROJ: /usr/lib/libproj.dll.a > -- * LIBXML2: /usr/lib/libxml2.dll.a > -- * POSTGIS: /usr/lib/libpq.a > -- * GEOS: /usr/local/lib/libgeos_c.dll.a > -- * FastCGI: /usr/lib/libfcgi.dll.a > -- * Oracle Spatial: disabled > -- * SDE: disabled > -- * Exempi XMP: disabled > -- * Optional features > -- * WMS SERVER: ENABLED > -- * WFS SERVER: ENABLED > -- * WCS SERVER: ENABLED > -- * SOS SERVER: ENABLED > -- * WMS CLIENT: ENABLED > -- * WFS CLIENT: ENABLED > -- * ICONV: disabled > -- * Thread-safety support: disabled > -- * KML output: ENABLED > -- * Z+M point coordinate support: disabled > -- * XML Mapfile support: disabled > -- * Mapscripts > -- * Python: ENABLED > -- * PHP: ENABLED > -- * PERL: ENABLED > -- * RUBY: disabled > -- * JAVA: disabled > -- * C&: disabled > -- * Apache Module (Experimental): disabled > -- > -- Will install files to /usr/local > -- Will install libraries to /usr/local/lib > -- Configuring done > CMake Error at CMakeLists.txt:233 (add_library): > Cannot find source file: > > //regex.c > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .in .txx > > -- Build files have been written to: /opt/mapserver/mapserver-6.4.1/build > > Gery@gery /opt/mapserver/mapserver-6.4.1/build > $ > -- > > then it stops. make and make install do nothing, just a "stop" message > appears: > > -- > Gery@gery /opt/mapserver/mapserver-6.4.1/build > $ make > make: *** No targets specified and no makefile found. Stop. > > Gery@gery /opt/mapserver/mapserver-6.4.1/build > $ make install > make: *** No rule to make target 'install'. Stop. > -- > > Any ideas? > > Thanks in advance, > > Gery -- 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
Threads
When trying to debug emacs in gdb, I see several threads, but it's not always clear who created those threads and what they're doing. As an example, I attached gdb to an emacs-X11 process (running under X) shortly after starting it, and I obtained the backtrace appended at the end of this message. I assume Thread 12 was created by gdb. Thread 6 appears to be a timer thread and Thread 2 appears to be a signal thread; I assume both of these were created by the Cygwin DLL. And Thread 1 is the main thread. I don't have any idea where the other threads came from. Presumably at least one of them was created by Glib. The situation is similar with emacs-w32 and emacs-nox, but with fewer threads. In general, is there a way I can understand where all the threads come from? My reason for asking is that we're still getting emacs bug reports on 64-bit Cygwin, with random crashes or assertion violations that are "impossible" according to the gdb backtraces. [*] So I'm wondering whether they're caused by interference from other threads. Or is there some other plausible explanation for "impossible" crashes? This can't just be a result of a gdb bug, because in at least one case the assertion can be shown to be valid by using printf instead of gdb. Ken [*] By "impossible" I mean that examination of the relevant variables in gdb shows that the assertions are in fact true. Two ongoing examples are http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18769 =thread apply all bt== Thread 12 (Thread 6288.0x554): #0 0x77b50591 in ntdll!DbgBreakPoint () at /c/Windows/SYSTEM32/ntdll.dll #1 0x77bf7f48 in ntdll!DbgUiRemoteBreakin () at /c/Windows/SYSTEM32/ntdll.dll #2 0x779f59ed in KERNEL32!BaseThreadInitThunk () at /c/Windows/system32/kernel32.dll #3 0x77b2c541 in ntdll!RtlUserThreadStart () at /c/Windows/SYSTEM32/ntdll.dll #4 0x in () Thread 11 (Thread 6288.0x2280): #0 0x77b52bba in ntdll!ZwWaitForWorkViaWorkerFactory () at /c/Windows/SYSTEM32/ntdll.dll #1 0x77b1fe3b in ntdll!RtlValidateHeap () at /c/Windows/SYSTEM32/ntdll.dll #2 0x00018004619b in _cygtls::call2(unsigned int (*)(void*, void*), void*, void*) (this=0x202, func=0x0, arg=0x5e82d0, buf=buf@entry=0x47bcd50) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100 #3 0x0001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), void*) (func=, arg=) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30 #4 0x779f59ed in KERNEL32!BaseThreadInitThunk () at /c/Windows/system32/kernel32.dll #5 0x77b2c541 in ntdll!RtlUserThreadStart () at /c/Windows/SYSTEM32/ntdll.dll #6 0x in () Thread 10 (Thread 6288.0x22c0): #0 0x77b52bba in ntdll!ZwWaitForWorkViaWorkerFactory () at /c/Windows/SYSTEM32/ntdll.dll #1 0x77b1fe3b in ntdll!RtlValidateHeap () at /c/Windows/SYSTEM32/ntdll.dll #2 0x00018004619b in _cygtls::call2(unsigned int (*)(void*, void*), void*, void*) (this=0x202, func=0x2929, arg=0x5e82d0, buf=buf@entry=0x4bbcd50) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100 #3 0x0001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), void*) (func=, arg=) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30 #4 0x779f59ed in KERNEL32!BaseThreadInitThunk () at /c/Windows/system32/kernel32.dll #5 0x77b2c541 in ntdll!RtlUserThreadStart () at /c/Windows/SYSTEM32/ntdll.dll #6 0x in () Thread 9 (Thread 6288.0x1e98): #0 0x77b515fa in ntdll!ZwDelayExecution () at /c/Windows/SYSTEM32/ntdll.dll #1 0x07fefda11203 in SleepEx () at /c/Windows/system32/KERNELBASE.dll #2 0x00018010d970 in thread_pipe(void*) (arg=0x600d2bfe0) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690 #3 0x000180044fc5 in cygthread::callfunc(bool) (this=this@entry=0x1801d0500 , issimplestub=issimplestub@entry=false) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51 #4 0x00018004552a in cygthread::stub(void*) (arg=arg@entry=0x1801d0500 ) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93 #5 0x00018004619b in _cygtls::call2(unsigned int (*)(void*, void*), void*, void*) (this=0x43bce00, func= 0x1800454d0 , arg=0x1801d0500 , buf=buf@entry=0x43bcd50) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100 #6 0x0001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), void*) (func=, arg=) at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30 #7 0x779f59ed in KERNEL32!BaseThreadInitThunk () at /c/Windows/system32/kernel32.dll #8 0x77b2c541 in ntdll!RtlUserThreadStart () at /c/Windows/SYSTEM32/ntdll.dll #9 0x in () Thread 8 (Thread 6288.0x1ae4): #0
Tester for openblas needed
Hi, before making an official cygwin package for OpenBlas (fast Blas) http://www.openblas.net/ I would like some test from potential users. The dynamic library is multicore, so it should work on "all" processors, but unfortunately I can only test on my dual Core i5-3320M. On this system the speedup of basic BLAS operation is notable. 1000x1000x1000 DGEMM tests give for x86_64 architecture 0.818047 s 2444.847301 MFLOPS x86_64 netlib reference 0.055000 s 36363.636364 MFLOPS x86_64 openblas 2.12 for i686 architecture 0.825001 s 2424.239486 MFLOPS i686netlib reference 0.095001 s 21052.409975 MFLOPS i686openblas 2.12 Libraries are available on: http://matzeri.altervista.org/x86/openblas/libopenblas_dynamic/ http://matzeri.altervista.org/x86_64/openblas/libopenblas_dynamic/ To use them is enough to copy the cygblas-0.dll in any path directory before "/usr/lib/lapack" where the lapack one is located. On http://matzeri.altervista.org/works/openblas/ there is also a DGEMM test routine, if you have no other benchmark. Thanks in advance Marco -- 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: Tester for openblas needed
before making an official cygwin package for OpenBlas (fast Blas) http://www.openblas.net/ I would like some test from potential users. The dynamic library is multicore, so it should work on "all" processors, but unfortunately I can only test on my dual Core i5-3320M. Neat, I'll give it a try. Do you have a cygport file you're working on that I could look at? I build OpenBLAS quite regularly, though almost always as a MinGW cross-compile, for use with Julia (www.julialang.org if you're not familiar). -Tony -- 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: Tester for openblas needed
On 10/20/2014 4:00 PM, Tony Kelman wrote: before making an official cygwin package for OpenBlas (fast Blas) http://www.openblas.net/ I would like some test from potential users. The dynamic library is multicore, so it should work on "all" processors, but unfortunately I can only test on my dual Core i5-3320M. Neat, I'll give it a try. Do you have a cygport file you're working on that I could look at? I build OpenBLAS quite regularly, though almost always as a MinGW cross-compile, for use with Julia (www.julialang.org if you're not familiar). look in the source package http://matzeri.altervista.org/x86_64/openblas/ -Tony Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin.com/cgi-bin not found
On Mon, Oct 20, 2014 at 2:33 AM, Corinna Vinschen wrote: > Removed at some point in the past. You referenced the correct path > yourself in the mail the above link points to The following example links do not work http://cygwin.com/cgi-bin http://cygwin.com/cgi-bin/cvsweb.cgi/htdocs/cgi-bin2?cvsroot=cygwin This is a problem because the second link for example was the only page to host the source of "package-grep.cgi". So either those links need to be restored, or new links need to be revealed. -- 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: gfortran and lapack problem
I'm using 64 bit Cygwin. I guess that the "compilation finished" message I got is because of my compiling interface, so I don't think is important. Regarding the checks you suggested: $ cygcheck gfortran Found: D:\Cygwin64\bin\gfortran.exe Found: D:\Cygwin64\bin\gfortran.exe Found: D:\Cygwin64\bin\gfortran.exe D:\Cygwin64\bin\gfortran.exe And then a bunch of dll's. When I check gfortran I get $ which -a gfortran /usr/bin/gfortran /usr/bin/gfortran /usr/bin/gfortran While for blas: $ which -a cygblas-0.dll /usr/lib/lapack/cygblas-0.dll Thanks! On Mon, Oct 20, 2014 at 4:10 AM, Tony Kelman wrote: >> I compile it as gfortran MyTest.f90 -o MyTest -llapack -lblas. I don't >> get any errors (it says "compilation finished"), but the output file >> doesn't print anything (neither the strings, or the variable info). If >> I comment the "CALL DGESV" line, it does print everything (with >> info=0, of course). > > > 32 bit or 64 bit Cygwin? Works for me, I get > > $ gfortran MyTest.f90 -o MyTest -llapack -lblas > > $ ./MyTest > Printing the results > 0 > End printing > > So no "compilation finished" message. Might you have some other > version of gfortran on your path? I believe cygcheck.out would > list some of this information. Other things to check: > > which -a gfortran > which -a cygblas-0.dll > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin.com/cgi-bin not found
On Oct 20 10:00, Steven Penny wrote: > On Mon, Oct 20, 2014 at 2:33 AM, Corinna Vinschen wrote: > > Removed at some point in the past. You referenced the correct path > > yourself in the mail the above link points to > > The following example links do not work > > http://cygwin.com/cgi-bin > http://cygwin.com/cgi-bin/cvsweb.cgi/htdocs/cgi-bin2?cvsroot=cygwin > > This is a problem because the second link for example was the only > page to host the source of "package-grep.cgi". So either those links > need to be restored, or new links need to be revealed. Try wget https://cygwin.com/cgi-bin2/package-grep.cgi Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFJfe0iU0D7.pgp Description: PGP signature
Re: cygwin.com/cgi-bin not found
On Mon, Oct 20, 2014 at 10:48 AM, Corinna Vinschen wrote: > Try > > wget https://cygwin.com/cgi-bin2/package-grep.cgi No. I am not trying to search for a package. I am trying to view the source code for the Perl file "package-grep.cgi" and other files that were under "cgi-bin". -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin.com/cgi-bin not found
On 20/10/2014 16:00, Steven Penny wrote: On Mon, Oct 20, 2014 at 2:33 AM, Corinna Vinschen wrote: Removed at some point in the past. You referenced the correct path yourself in the mail the above link points to The following example links do not work http://cygwin.com/cgi-bin I would think all you are checking here, and with your previous script is that the cgi-bin directory doesn't allow listings, which I would suspect has always been the case. http://cygwin.com/cgi-bin/cvsweb.cgi/htdocs/cgi-bin2?cvsroot=cygwin This is a problem because the second link for example was the only page to host the source of "package-grep.cgi". So either those links need to be restored, or new links need to be revealed. The clue should be in the URL that this a web view of a CVS repository. The files are still available via CVS. "cvs -d :pserver:anon...@sourceware.org:/cvs/cygwin co htdocs" cvsweb on sourceware has been retired in favour of viewvc, but it seems there are still some repositories and redirects missing from that. -- 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: gfortran and lapack problem
On 10/20/2014 5:42 PM, Christian wrote: I'm using 64 bit Cygwin. I guess that the "compilation finished" message I got is because of my compiling interface, so I don't think is important. can you remove the interface usage an use only gfortran MyTest.f90 -o MyTest -llapack -lblas For my it works fine $ ./MyTest.exe Printing the results 0 End printing Additional question, which terminal are you using ? Thanks! Regards Marco -- 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: Tester for openblas needed
look in the source package http://matzeri.altervista.org/x86_64/openblas/ Thanks. I'm a little surprised the cygblas-0.dll (x86_64, 0.2.12-1) does not appear to be linked to libgfortran. Were you seeing your test executables using multiple cores? I think you may have to build with USE_THREAD=1 to enable threading (or USE_OPENMP=1 for openmp)? I may be doing this wrong, but I'm getting errors from your openblas build, but not the reference blas package, when I run the following: $ curl -O https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.f $ gfortran -o sblat2 sblat2.f -lblas $ rm -f SBLAT2.SUMM $ curl https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.dat | ./sblat2 This outputs messages like: ** On entry to SGEMV parameter number 1 had an illegal value and so on for the other single-precision level 2 functions in that test. This does seem to work okay on Linux or an existing i686-w64-mingw32 build. -Tony -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: libxml2-2.9.2-1
The following packages have been updated for the Cygwin distribution: * libxml2-2.9.2-1 * libxml2-devel-2.9.2-1 * libxml2-doc-2.9.2-1 * python-libxml2-2.9.2-1 Libxml2 is the XML C parser and toolkit developed for the GNOME project. Though the library is written in C, a variety of language bindings make it available in other environments. This is an update to the latest upstream release, which includes fixes for CVE-2014-0191 and CVE-2014-3660. -- 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: gfortran and lapack problem
It appears that it is a problem with the terminal I was using. I was compiling my code using the smart-compile package for emacs, and then printing the output using the emacs-shell. The compilation was not the problem (I compiled it from the Cygwing terminal as well with the same results). But when I used the Cygwin terminal to print the results everything works. This is kind of odd because the emacs-shell had worked for me before (w/o blas or lapack), but this is of course not a Cygwin's problem. Sorry for wasting your time with this silly problem. Thanks so much for your help. On Mon, Oct 20, 2014 at 11:57 AM, Marco Atzeri wrote: > On 10/20/2014 5:42 PM, Christian wrote: >> >> I'm using 64 bit Cygwin. >> I guess that the "compilation finished" message I got is because of my >> compiling interface, so I don't think is important. > > > can you remove the interface usage an use only > >gfortran MyTest.f90 -o MyTest -llapack -lblas > > For my it works fine > > $ ./MyTest.exe > Printing the results >0 > End printing > > Additional question, which terminal are you using ? > > >> Thanks! > > Regards > Marco > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Threads
On Oct 20 09:03, Ken Brown wrote: > When trying to debug emacs in gdb, I see several threads, but it's not > always clear who created those threads and what they're doing. As an > example, I attached gdb to an emacs-X11 process (running under X) shortly > after starting it, and I obtained the backtrace appended at the end of this > message. > > I assume Thread 12 was created by gdb. Yes, that's the debugging thread created by the OS when a debugger connects. Thread 11 and 10 seem to be dead threads which have been added to the thread pool?!? Thread 9 is a worker thread for select on a pipe. Thread 8 and 7 are unrecognizable, I'd bet on a select call in at least one of them. > Thread 6 appears to be a timer thread Right, thread 6 is a worker thread for a timer_settime call (also called from setitimer, alarm, ualarm). Thread 5 is another select on a pipe, thread 4 and 3 again not recognizable. > and Thread 2 appears to be a signal thread; Right. > I assume both of these > were created by the Cygwin DLL. And Thread 1 is the main thread. Right. Thread 2, 5, 6, 9 are Cygwin-created threads. Threads 3, 4, 7 and 8 appear to be application-created threads. At least one of them is waiting in a select call, waiting for two pipe handles, or two of them waiting for one each. Select itself starts threads a lot. Threads 10 and 11 seemed to be ignorable, but I never saw threads waiting in WaitForWorkViaWorkerFactory myself. Cygwin does not utilize the OS thread pools by itself, rather it implements its own. > I don't > have any idea where the other threads came from. Presumably at least one of > them was created by Glib. > > The situation is similar with emacs-w32 and emacs-nox, but with fewer threads. > > In general, is there a way I can understand where all the threads come from? There's no simple generic way to do that, afaik. One big problem is to have all the symbols. You should definitely install the debuginfo packages of all potentially affected packages, not only cygwin-debuginfo. If you want to find out where threads are called from the application, you might get a clue by running emacs under GDB and set a breakpoint to pthread_create. Unless, of course, any component starts threads by calling the Windows function CreateThread. There's no guarantee that Cygwin's thread handling will catch these, even though it tries. > My reason for asking is that we're still getting emacs bug reports on 64-bit > Cygwin, with random crashes or assertion violations that are "impossible" > according to the gdb backtraces. [*] So I'm wondering whether they're > caused by interference from other threads. > > Or is there some other plausible explanation for "impossible" crashes? This > can't just be a result of a gdb bug, because in at least one case the > assertion can be shown to be valid by using printf instead of gdb. One of the headaches when porting is sometimes the ABI. While on Linux the first 6 arguments to a function are given in registers, on Windows only 4 args are in registers. This can result in bugs when calling functions with more than 4 parameters, which are invisible on Linux, due to the way 32 bit parameter are stored in registers on x86_64. This happened to us already for at least one package. Other than that, it could be a bug in any of the affected components, including Cygwin. I'm sorry, but I don't even have a tang of a hunch, even after reading the emacs bugreport entries :( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6vuPf2NuiU.pgp Description: PGP signature
Re: perl -d causes completion to fail
On 10/20/2014 4:23 AM, Adam Dinwoodie wrote: On Wed, Oct 15, 2014 at 03:08:42PM -0700, Andrew DeFaria wrote: On 10/15/2014 2:30 PM, Andrew DeFaria wrote: Adefaria-lt:ls /etc/bash_completion.d/perl ls: cannot access /etc/bash_completion.d/perl: No such file or directory Adefaria-lt:ls /usr/share/bash-completion/completions/perl /usr/share/bash-completion/completions/perl Adefaria-lt: I think you mean /usr/share/bash-completion/completions/perl... I think the problem is that it's parsing the next token after -d and -dt looking for :debugger and never things that maybe there's no debugger name (see perldoc perldebug). Whatever you're using doesn't seem to be the Cygwin bash-completion package. Both x86 and x86_64 install /etc/bash_completion.d/perl: https://cygwin.com/packages/x86/bash-completion/bash-completion-1.3-1 https://cygwin.com/packages/x86_64/bash-completion/bash-completion-1.3-1 Before we go any further with anything else, I think your next step should probably be to install the Cygwin bash-completion package and check what the behaviour is there. I ran setup and I see a "Keep" for 2.1-1 of bash-completion. I believe that means it's already installed. Additionally: $ ls /usr/share/bash_completion.d/perl ls: cannot access /usr/share/bash_completion.d/perl: No such file or directory $ ll /usr/share/bash-completion/completions/perl -rw-r--r-- 1 adefaria Domain Users 3569 Feb 9 2014 /usr/share/bash-completion/completions/perl $ cygcheck -f /usr/share/bash-completion/completions/perl bash-completion-2.1-1 $ -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin.com/cgi-bin not found
Greetings, Steven Penny! >> Removed at some point in the past. You referenced the correct path >> yourself in the mail the above link points to > The following example links do not work > http://cygwin.com/cgi-bin > http://cygwin.com/cgi-bin/cvsweb.cgi/htdocs/cgi-bin2?cvsroot=cygwin > This is a problem because the second link for example was the only page to > host > the source of "package-grep.cgi". So either those links need to be restored, > or > new links need to be revealed. You didn't made the issue clear. What part of the Cygwin website is referencing these links? I.e. what does not work for you on the website? -- WBR, Andrey Repin (anrdae...@yandex.ru) 20.10.2014, <22:25> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Threads
On Oct 20 18:43, Corinna Vinschen wrote: > On Oct 20 09:03, Ken Brown wrote: > > When trying to debug emacs in gdb, I see several threads, but it's not > > always clear who created those threads and what they're doing. As an > > example, I attached gdb to an emacs-X11 process (running under X) shortly > > after starting it, and I obtained the backtrace appended at the end of this > > message. > > > > I assume Thread 12 was created by gdb. > [...] > > I don't > > have any idea where the other threads came from. Presumably at least one of > > them was created by Glib. > > > > The situation is similar with emacs-w32 and emacs-nox, but with fewer > > threads. > > > > In general, is there a way I can understand where all the threads come from? > > There's no simple generic way to do that, afaik. > > One big problem is to have all the symbols. You should definitely > install the debuginfo packages of all potentially affected packages, not > only cygwin-debuginfo. If you want to find out where threads are called > from the application, you might get a clue by running emacs under GDB and > set a breakpoint to pthread_create. Btw., I don't know if that helps, but the function names of native Windows functions given in the GDB backtrace may be off because GDB doesn't have access to the Windows DLL symbol tables. If you want to analyze the stacks from that side, you should install WinDbg(*) and the symbol files for your OS(**). If you start the process from WinDbg, you can better see the Windows functions called from these threads, while not getting any info about the functions from inside the application or the Cygwin DLLs. HTH, Corinna (*) http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx (**) http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqlKMK9_Vw6.pgp Description: PGP signature
Re: cygwin.com/cgi-bin not found
On Mon, Oct 20, 2014 at 1:27 PM, Andrey Repin wrote: > You didn't made the issue clear. What part of the Cygwin website is > referencing these links? I.e. what does not work for you on the website? http://cygwin.com/ml/cygwin/2014-08/msg00179.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Threads
On 10/20/2014 3:03 PM, Corinna Vinschen wrote: On Oct 20 18:43, Corinna Vinschen wrote: On Oct 20 09:03, Ken Brown wrote: When trying to debug emacs in gdb, I see several threads, but it's not always clear who created those threads and what they're doing. As an example, I attached gdb to an emacs-X11 process (running under X) shortly after starting it, and I obtained the backtrace appended at the end of this message. I assume Thread 12 was created by gdb. [...] I don't have any idea where the other threads came from. Presumably at least one of them was created by Glib. The situation is similar with emacs-w32 and emacs-nox, but with fewer threads. In general, is there a way I can understand where all the threads come from? There's no simple generic way to do that, afaik. One big problem is to have all the symbols. You should definitely install the debuginfo packages of all potentially affected packages, not only cygwin-debuginfo. If you want to find out where threads are called from the application, you might get a clue by running emacs under GDB and set a breakpoint to pthread_create. Btw., I don't know if that helps, but the function names of native Windows functions given in the GDB backtrace may be off because GDB doesn't have access to the Windows DLL symbol tables. If you want to analyze the stacks from that side, you should install WinDbg(*) and the symbol files for your OS(**). If you start the process from WinDbg, you can better see the Windows functions called from these threads, while not getting any info about the functions from inside the application or the Cygwin DLLs. Thanks, I'll give that a try. One of the headaches when porting is sometimes the ABI. While on Linux the first 6 arguments to a function are given in registers, on Windows only 4 args are in registers. This can result in bugs when calling functions with more than 4 parameters, which are invisible on Linux, due to the way 32 bit parameter are stored in registers on x86_64. This happened to us already for at least one package. Am I right in thinking this can only be an issue if the source includes assembler code? Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl -d causes completion to fail
On 10/20/2014 1:04 PM, Andrew DeFaria wrote: On 10/20/2014 4:23 AM, Adam Dinwoodie wrote: Whatever you're using doesn't seem to be the Cygwin bash-completion package. Both x86 and x86_64 install /etc/bash_completion.d/perl: https://cygwin.com/packages/x86/bash-completion/bash-completion-1.3-1 https://cygwin.com/packages/x86_64/bash-completion/bash-completion-1.3-1 Before we go any further with anything else, I think your next step should probably be to install the Cygwin bash-completion package and check what the behaviour is there. I ran setup and I see a "Keep" for 2.1-1 of bash-completion. I believe that means it's already installed. It means you installed it from some source (Cygwin Ports maybe?) other than a Cygwin mirror. As Adam said, Cygwin provides version 1.3-1. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl -d causes completion to fail
On 10/20/2014 1:05 PM, Ken Brown wrote: On 10/20/2014 1:04 PM, Andrew DeFaria wrote: On 10/20/2014 4:23 AM, Adam Dinwoodie wrote: Whatever you're using doesn't seem to be the Cygwin bash-completion package. Both x86 and x86_64 install /etc/bash_completion.d/perl: https://cygwin.com/packages/x86/bash-completion/bash-completion-1.3-1 https://cygwin.com/packages/x86_64/bash-completion/bash-completion-1.3-1 Before we go any further with anything else, I think your next step should probably be to install the Cygwin bash-completion package and check what the behaviour is there. I ran setup and I see a "Keep" for 2.1-1 of bash-completion. I believe that means it's already installed. It means you installed it from some source (Cygwin Ports maybe?) other than a Cygwin mirror. As Adam said, Cygwin provides version 1.3-1. I've never installed any Cygwin stuff from anything other than setup.exe. The Cygwin mirror I typically use is http://mirrors.kernal.org. Oddly enough, looking at it now, I see Current as 2.1-1 and "new" as 1.3-1. Huh? OK... Installing "new"... Well now I do have 1.3-1 and I have an /etc/bash_completion.d/perl, but it behaves the same... :-( -- Andrew DeFaria http://defaria.com -- 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: Tester for openblas needed
On 10/20/2014 6:16 PM, Tony Kelman wrote: look in the source package http://matzeri.altervista.org/x86_64/openblas/ Thanks. I'm a little surprised the cygblas-0.dll (x86_64, 0.2.12-1) does not appear to be linked to libgfortran. Were you seeing your test executables using multiple cores? I think you may have to build with USE_THREAD=1 to enable threading (or USE_OPENMP=1 for openmp)? openblas is written in C USE_THREAD=1 and USE_OPENMP=1, can be used dynamically ; if I am not wrong. I may be doing this wrong, but I'm getting errors from your openblas build, but not the reference blas package, when I run the following: $ curl -O https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.f $ gfortran -o sblat2 sblat2.f -lblas $ rm -f SBLAT2.SUMM $ curl https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.dat | ./sblat2 This outputs messages like: ** On entry to SGEMV parameter number 1 had an illegal value and so on for the other single-precision level 2 functions in that test. This does seem to work okay on Linux or an existing i686-w64-mingw32 build. It fails also on the netlib blas reference so it is not a specific openblas issue. It must be something more general like http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01441.html During the OpenBlas build the test is passed $ cat SBLAT2.SUMM -- TESTS OF THE REAL LEVEL 2 BLAS THE FOLLOWING PARAMETER VALUES WILL BE USED: FOR N 0 1 2 3 73163 FOR K 0 1 2 4 FOR INCX AND INCY 1 2-1-2 FOR ALPHA 0.0 1.0 0.7 FOR BETA 0.0 1.0 0.9 ROUTINES PASS COMPUTATIONAL TESTS IF TEST RATIO IS LESS THAN 16.00 RELATIVE MACHINE PRECISION IS TAKEN TO BE 1.2E-07 SGEMV PASSED THE TESTS OF ERROR-EXITS SGEMV PASSED THE COMPUTATIONAL TESTS ( 4324 CALLS) [cut] SSYR2 PASSED THE TESTS OF ERROR-EXITS SSYR2 PASSED THE COMPUTATIONAL TESTS ( 577 CALLS) SSPR2 PASSED THE TESTS OF ERROR-EXITS SSPR2 PASSED THE COMPUTATIONAL TESTS ( 577 CALLS) END OF TESTS - but the test program is built static, not linked to the dll. -Tony -- 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: Setup 2.774 texlive postinstall takes 10+ hours
I downloaded Setup.exe version 2.850 (32 bit) on Oct 18, 2014 and used it to install cygwin from scratch on an Asus Eee notebook with Atom N455 cpu. I tried to install only the default packages but it seems like that took about 8 hours to download overnight. The install went okay until it came to the /etc/postinstall/texlive-collection-basic.sh which seemed to hang for at least 12 hours. Thinking it was hung I canceled the install, but then I found this longish thread going back several years, so I restarted the install and let it run for at least 24 hours and see no more happening. It sits the whole time on this script. The "Total:" line shows 99% done and the "Package:" line shows zero progress the whole time. Is there a way to install Cygwin without installing this package, which seems to have been included in the default selection? Now that I seem to have it included can I take it out without breaking something that is too important to do without? When I restarted the install everything said "default" and I didn't change anything. Since it doesn't ever finish I don't see any log file, or indeed, ever a log directory. Thank you, Don MacDougall -- View this message in context: http://cygwin.1069669.n5.nabble.com/Setup-2-774-texlive-postinstall-takes-10-hours-resending-due-to-cygwin-bounce-tp92260p112040.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: cygcheck -s segfaults in cygwin64 on Win7Pro-64
Apparently not BLODA (plus I'm not running anything on the BLODA list). Instead, I found that COMSPEC needs to be set in the environment or I get a segfault as shown in my previous email below. I don't know why that is, but I can easily demonstrate it. - Original Message - > From: Marco Atzeri > To: cygwin@cygwin.com > Cc: > Sent: Friday, October 17, 2014 11:59 PM > Subject: Re: cygcheck -s segfaults in cygwin64 on Win7Pro-64 > > On 10/17/2014 11:52 PM, John Wiersba wrote: >> With a 3-week-old (i.e. recent) install of cygwin, which otherwise > functions well: >> >> $ uname -a >> CYGWIN_NT-6.1 DESKTOP-NAME 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin >> >> >> >> $ PATH=/bin:/usr/bin cygcheck -s >> Cygwin Configuration Diagnostics >> Current System Time: Fri Oct 17 17:37:27 2014 >> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 >> Path: D:\cygwin\bin >> D:\cygwin\bin >> Segmentation fault >> > > it works fine here > $ PATH=/bin:/usr/bin cygcheck -s > > Cygwin Configuration Diagnostics > Current System Time: Sat Oct 18 04:49:42 2014 > > Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 > > Path: E:\cygwin64\bin > E:\cygwin64\bin > > Output from E:\cygwin64\bin\id.exe > ... > zlib0 1.2.8-1OK > > also from CMD prompt no issue. > >> Also, I notice that when PATH has no :, cygcheck prints bogus information: >> $ PATH=/bin cygcheck -s >> >> Cygwin Configuration Diagnostics >> Current System Time: Fri Oct 17 17:38:27 2014 >> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 >> Path: D >> \cygwin\bin >> Segmentation fault >> >> >> Running under gdb: >> >> $ PATH=/bin gdb cygcheck > [cut] >> (gdb) r -s >> Starting program: /bin/cygcheck -s >> [New Thread 5492.0x11ec] >> >> Cygwin Configuration Diagnostics >> Current System Time: Fri Oct 17 17:46:49 2014 >> >> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 >> >> Path: D >> \cygwin\bin >> [Inferior 1 (process 5492) exited with code 0305] >> (gdb) >> > > BLODA ? > > >> >> All of this was in preparation for reporting another problem with run.exe > (which flashes a console window instead of hiding it). >> >> 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 > -- 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: Tester for openblas needed
openblas is written in C More assembly than C according to github's count. I'm used to building the full version of openblas including their optimized implementations of lapack routines, which bring in libgfortran. So nevermind. USE_THREAD=1 and USE_OPENMP=1, can be used dynamically ; if I am not wrong. What does your Makefile.conf say for NUM_CORES? I can't seem to get a test program with your build to use more than 2 cores (I have 4 + HT) by setting the OPENBLAS_NUM_THREADS environment variable. -Tony -- 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: Setup 2.774 texlive postinstall takes 10+ hours
On 10/20/2014 6:38 PM, Don MacDougall wrote: I downloaded Setup.exe version 2.850 (32 bit) on Oct 18, 2014 and used it to install cygwin from scratch on an Asus Eee notebook with Atom N455 cpu. I tried to install only the default packages but it seems like that took about 8 hours to download overnight. The install went okay until it came to the /etc/postinstall/texlive-collection-basic.sh which seemed to hang for at least 12 hours. Thinking it was hung I canceled the install, but then I found this longish thread going back several years, so I restarted the install and let it run for at least 24 hours and see no more happening. It sits the whole time on this script. The "Total:" line shows 99% done and the "Package:" line shows zero progress the whole time. Is there a way to install Cygwin without installing this package, which seems to have been included in the default selection? I don't know what happened, but you must have inadvertently selected some packages to install that you didn't intend to choose. There are no texlive packages in a default installation. Ken -- 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: Setup 2.774 texlive postinstall takes 10+ hours
On 10/20/2014 10:09 PM, Ken Brown wrote: On 10/20/2014 6:38 PM, Don MacDougall wrote: I downloaded Setup.exe version 2.850 (32 bit) on Oct 18, 2014 and used it to install cygwin from scratch on an Asus Eee notebook with Atom N455 cpu. I tried to install only the default packages but it seems like that took about 8 hours to download overnight. The install went okay until it came to the /etc/postinstall/texlive-collection-basic.sh which seemed to hang for at least 12 hours. Thinking it was hung I canceled the install, but then I found this longish thread going back several years, so I restarted the install and let it run for at least 24 hours and see no more happening. It sits the whole time on this script. The "Total:" line shows 99% done and the "Package:" line shows zero progress the whole time. Is there a way to install Cygwin without installing this package, which seems to have been included in the default selection? I don't know what happened, but you must have inadvertently selected some packages to install that you didn't intend to choose. There are no texlive packages in a default installation. Did you by any chance click on the word "Default" near the top of the screen? If so, it would have changed to "Install", which means you've chosen to install everything. Ken -- 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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)
If I changed it away from "default" was accidental. I did look through the list of packages to be installed and it looked like quite a list and all binary packages were checked but not the source packages. But, since the first time I have looked when I restarted the installation and it said "default" and I didn't change it. If it was accidentally changed the first time, would it then say "all" when I restart the installation? If so, then I know it says "default" when I restarted it. Don -- View this message in context: http://cygwin.1069669.n5.nabble.com/Setup-2-774-texlive-postinstall-takes-10-hours-resending-due-to-cygwin-bounce-tp92260p112045.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Setup 2.774 texlive postinstall takes 10+ hours (resending due to cygwin bounce)
Oops, what I meant to say was that it says "default" not "install" when I restart the installation. If I had it set to "install" the first time rather than "default", presumably it would still say that on restarting, I would imagine, though this is my first time in at least 10 years to try to install cygwin since I usually use linux, not Windows. Don -- View this message in context: http://cygwin.1069669.n5.nabble.com/Setup-2-774-texlive-postinstall-takes-10-hours-resending-due-to-cygwin-bounce-tp92260p112046.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Setup 2.774 texlive postinstall takes 10+ hours
> I don't know what happened, but you must have inadvertently selected > some packages to install that you didn't intend to choose. There are no > texlive packages in a default installation. If I somehow did something like this, is there an easy way to undo it other than to delete everything and start over? Since I've already downloaded everything I've no objection to having it install, especially since the install says it's 99% complete, but this one package seems to hold everything up and when I try to install everything else while uninstalling this one package, the installer still stalls at the same postinstall script. Might I presume that it can't uninstall till it first completes the install? If that's the case, then I suppose I'll just leave it set to install and let it run for 3 or 4 days in the hope it'll eventually complete. Most of the other postinstall scripts and the whole rest of the install process ran in no more than a few hours. Don -- View this message in context: http://cygwin.1069669.n5.nabble.com/Setup-2-774-texlive-postinstall-takes-10-hours-resending-due-to-cygwin-bounce-tp92260p112047.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Tester for openblas needed
On 10/21/2014 1:33 AM, Tony Kelman wrote: openblas is written in C More assembly than C according to github's count. I'm used to building the full version of openblas including their optimized implementations of lapack routines, which bring in libgfortran. So nevermind. I avoided to include lapack as for compatibility I will need to split exactly as netlib in cygblas-0.dll cyglapack-0.dll something for the future. USE_THREAD=1 and USE_OPENMP=1, can be used dynamically ; if I am not wrong. What does your Makefile.conf say for NUM_CORES? I can't seem to get a test program with your build to use more than 2 cores (I have 4 + HT) by setting the OPENBLAS_NUM_THREADS environment variable. NUM_CORES=2 I will ask on the OpenBlas mailing list -Tony Regards Marco -- 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
