B
Sent from my iPhone -- 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: Octave/HDF5 library/header mismatch
On 21/06/2016 06:20, Gavin King wrote: Hello My apologies if this is a bit verbose, or if the terminology is a bit wrong; I know enough to get myself into trouble but not enough to communicate problems well. Hi Gavin, nice to hear you. After updating cygwin, a working script failed, causing octave to exit (with an error code 6). A minimal example is attached; it opens octave, creates a simple vector of values, and tries to save the workspace to disc. The error message is at the end. It appears there is a mismatch between the compiled octave version and the most recent version of the HDF5 headers. The current version of the package octave is 4.0.1-1. Reverting it to the previous version makes no difference. Reverting the package libhdf5_10 from the current version 1.8.17-1 to the previous version 1.8.16-1 means that octave 4.0.1-1 can save the workspace. So: workaround: revert libhdf5_10 to 1.8.16-1. Presumably, the current version of octave was compiled at an inopportune point; I don't think this is something that I can remedy myself, is it? the official workaround is mentioned on the warning message "You can, at your own risk, disable this warning by setting the environment variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'. Setting it to 2 or higher will suppress the warning messages totally. Headers are 1.8.16, library is 1.8.17" so if you use, before running octave export HDF5_DISABLE_VERSION_CHECK=1 you will still see the warning but the action will be completed export HDF5_DISABLE_VERSION_CHECK=2 will suppress also the warning. I think this is the correct place to report this to; it isn't a problem per se with the individual programs, but with the way they're packed together. I think. Do correct me if I am wrong; I'm a bit new to this whole business. It is the right place. This problem is clearly a hdf5 upstream problem and a questionable design choice. I am following with them https://lists.hdfgroup.org/pipermail/hdf-forum_lists.hdfgroup.org/2016-June/009564.html yours Gavin King 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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
Frank Brill samsung.com> writes: > > I am having trouble building an open source project using cmake under Cygwin64 with the latest tools > (setup-x86_64.exe version 2.874). > > I was able to successfully build the project with 32-bit Cygwin with the latest tools: gcc 5.4.0, gnu make > 4.2.1, and cmake 3.3.2. I'm at a conference this week so really busy, but it sounds like I may need to update cmake to the latest version (which is overdue anyway) if something in the latest gcc is unhappy. Can you provide full reproduction steps, a source repo or tarball to download? Also looking into (and posting) the full content of the cmake error/output log files might provide more information about what the problem is. Thanks, 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] TEST RELEASE: Cygwin 2.5.2-0.2
Hi Cygwin friends and users, I released a new Cygwin TEST version 2.5.2-0.2. 2.5.2 will be a plain bugfix release, plus a few assorted improvements under the hood. Please test. Only regressions compared to 2.5.1 are currently on the radar. - HEADSUP The release is planned for this Thursday, 2016-06-21, combined with a little surprise package. Please give this test release a quick once over, especially to test that normal operation still works, as well as in terms of the additional patches applied to fix https://cygwin.com/ml/cygwin/2016-06/msg00269.html - What changed: - - select(2) now supports timeouts less than a Windows tick (10-16 ms). Bug Fixes - - Fix an error message depending on the system header inclusion order. Addresses: https://cygwin.com/ml/cygwin-developers/2016-05/msg3.html - Fix non-POSIXy scheduler priority handling. Addresses: Bugreport via private email - Allow mmap to map regions > 4 Gigs on 64 bit. Addresses: https://cygwin.com/ml/cygwin/2016-05/msg00140.html - Fix realpath(3) for incoming paths starting with long path prefixes. Addresses: https://sourceware.org/ml/cygwin/2016-04/msg00281.html - Fix a usage of INT_MAX (required limits.h) in math.h Addresses: Report on #cygwin-developers - Fix using wrong inode number on newly created files. Addresses: https://cygwin.com/ml/cygwin/2016-06/msg00269.html Have fun, 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: 2.5.1: flock blocks when it shouldn't (NT-10.0, x86_64)
On Jun 21 06:04, RG wrote:
> Hello,
>
> I have encountered unexpected behavior when using flock.
> It will block forever, but to my understanding it should not.
> I've attached a simple program that would trigger the behavior.
>
> Regards,
> Alex
> #include
> #include
> #include
>
> FILE *fp;
>
> void main() {
> unlink("a"); unlink("b");
>
> fp = fopen("a", "wb"); // file a
>
> printf("lock a\n");
> flock(fileno(fp), LOCK_EX);
>
> fwrite("TEST", sizeof(char), 4, fp);
>
> printf("unlock a\n");
> flock(fileno(fp), LOCK_UN);
> fclose(fp);
>
> fp = fopen("b", "wb"); // file b
>
> printf("lock b\n");
> flock(fileno(fp), LOCK_EX); // hang
>
> fwrite("TEST", sizeof(char), 4, fp);
>
> printf("unlock b\n");
> flock(fileno(fp), LOCK_UN);
> fclose(fp);
> }
Thank you for the report and especially the testcase!
This is one of those long-standing problems where you shake your
head violently and wonder why nobody noticed this earlier. The
problem only occurs for newly created files, and only if they get
created in the same parent dir.
What happoens is that the inode number for the files (which is crucial
for flock) is yet incorrectly the inode number of the parent directory
after fopen. However, due to the way fwrite works, its call results in
fetching the correct inode number of the file. The subsequent flock
fails to unlock because searching the file by inode number suddenly
fails.
I uploaded new developer snapshots on https://cygwin.com/snapshots/,
I also created and just announced a new test release 2.5.2-0.2 which
contains a fix for this problem and can be easily installed via setup.
Please give any of them a try ASAP.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
On 21/06/2016 03:43, Frank Brill wrote: I am having trouble building an open source project using cmake under Cygwin64 with the latest tools (setup-x86_64.exe version 2.874). I was able to successfully build the project with 32-bit Cygwin with the latest tools: gcc 5.4.0, gnu make 4.2.1, and cmake 3.3.2. I was also able to successfully build the project under Cygwin64 using older tools: gcc 4.9.3, gnu make 4.1, and cmake 3.3.2. But when I updated my Cygwin64 installation to the latest tools (gcc 5.4.0, gnu make 4.2.1, cmake 3.3.2) the build failed with the error message below. I tried wiping my Cygwin64 installation and reinstalling from scratch but got the same result. I thought it might be a PATH problem so I set my path the "/usr/bin" and still got the same result. The CMakeFiles/CMakeTmp directory mentioned in the error message below was created, but there's nothing in it. Can someone provide some advice that can help me fix my Cygwin64 installation so that cmake works properly? -- Frank $ cmake -DOPENVX_INCLUDES=$OPENVX_DIR/include -DOPENVX_LIBRARIES=$OPENVX_DIR/out/CYGWIN/x86_64/release/libopenvx.dll.a\;$OPENVX_DIR/out/CYGWIN/x86_64/release/libvxu.dll.a ../conformance_tests/ -- The C compiler identification is GNU 5.4.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- broken CMake Error at /usr/share/cmake-3.3.2/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/usr/bin/cc" is not able to compile a simple test program. It fails with the following output: Change Dir: /cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make.exe" "cmTC_5d15a/fast" /usr/bin/make -f CMakeFiles/cmTC_5d15a.dir/build.make CMakeFiles/cmTC_5d15a.dir/build make[1]: Entering directory '/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o /usr/bin/cc -o CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o -c /cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTC_5d15a.exe /usr/bin/cmake.exe -E cmake_link_script CMakeFiles/cmTC_5d15a.dir/link.txt --verbose=1 what is the content of cmake_link_script CMakeFiles/cmTC_5d15a.dir/link.txt /usr/bin/cc -Wl,--enable-auto-import CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o -o cmTC_5d15a.exe -Wl,--out-implib,libcmTC_5d15a.dll.a -Wl,--major-image-version,0,--minor-image-version,0 make[1]: Leaving directory '/cygdrive/c/Users/f.brill/Documents/OpenVX/trunk/packages/v_1_1/build64/CMakeFiles/CMakeTmp' Error running link command: No such file or directory that is very curious -- 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: Re: 2.5.1: flock blocks when it shouldn't (NT-10.0, x86_64)
Oh wow, I didn't expect such quick turnaround. Thanks Corinna! I've downloaded the snapshot and can confirm that it no longer hangs. Initially the bug manifested itself while I was using my django server and uploading files. However, there was no lead since there were no errors and the multi process nature of the server allowed it to continue operating. I shrugged it off, but later encountered the bug again in one of the files managing operations. With a little curiosity I managed to pit point the code in question. Luck was on my side. Anyway, thanks again. You made my day. Now I no longer need to run a VM to work on with my django application. -RG -- 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: xorg-server-1.18.3-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.18.3-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 1.18.2-1: * In multiwindow mode, enable the -compositewm option by default, so top-level window contents which are occluded are shown correctly in task bar and task switcher previews. Add a -nocompositewm option so it can be disabled. * Fix any custom sysmenu configured in .XWinrc not being used when window is initially shown (Thanks to Colin Harrison) [1] https://lists.x.org/archives/xorg-announce/2016-April/002683.html x86: 9c3feb4849359332b81b9b407c432d317204ea7cfa314cc1aff260ffc4747b1dfe93ade65427e6fecc0d3e902ac18bf4408f35fd89dc8eb4d190e4a31f33d519 *xorg-server-1.18.3-1-src.tar.xz 6daaac7a0f15063ce91a716848c588f095def328b7af607cac065d8a6b04db1e71c87e03221aee3defd36ce301e7ca6f6a5b9670afafbfd486cb8b46459e1c8e *xorg-server-1.18.3-1.tar.xz b9be0e372cfe3a6633b9d7ca9dfa8bb3b34f11d1d2b832d0337691f40e56c1cc740f33fb92c1bd793bd03670163cceaf8f23856ceee4b83f8a85963c779d05a6 *xorg-server-common-1.18.3-1.tar.xz f99b1cdc9da8c5b424790c9abfec0d30b8240656571d7c3cd198a3108748b87ba80bf7d6958df1d2478ba85e3b489967d8b8a138bfb7b6423e269a3c97663367 *xorg-server-debuginfo-1.18.3-1.tar.xz 6e9471e51bd41c81a77a9e99506f23a5d90be63a50e8b2c22805d90ad9b3865b417a35048791185bafa8b139b5d36a3eb8184bcbd8eaa3153070b8518d48cd50 *xorg-server-devel-1.18.3-1.tar.xz eec996bef4823082672b5d9cdf46212f2399d11c16d0f28e8e8c43081424f13262ba78f6bc0d9c501c9efeb16cd72381010392282b5f86d156905d603b29a064 *xorg-server-dmx-1.18.3-1.tar.xz 928f1d2284f1b2f266fbead71b46e01783a4888d442f5d5848117269fdafe3c9320dabaec03e242137b3ccd7a269398d635a59c9c00ad788cae021d0f675aee4 *xorg-server-extra-1.18.3-1.tar.xz 3a3d7a572b0ab0db4d461dca169430f8a68b6361bad89e50f0ea913d716155965aab22abbcea5014c97a74c1a331c9ae1c4e4792e7de973eca914ad3469d8240 *xwinclip-1.18.3-1.tar.xz x86_64: 0350c0caf1afbb49eb2a0f470885e971361d6631994254f0654f8e4f9bee8c7951e1edeca45277c9b79acd02d2d7b28b494761a938f1e90eb204f2e6e443313c *xorg-server-1.18.3-1-src.tar.xz 52f2b2cd97a4648cf259a816d6236fb6e3db828103938e3b76d4507d9ef0d44ba824e807f5be590ba16a121396e76410eca481eab0b2e5f0e28e09307770e5a7 *xorg-server-1.18.3-1.tar.xz aeb6de264db293e1268076bc38969b9833267f0ef8008fbf9182e950f0613de94f1046972c8120999a849aad24628c22d2a84487d9b8c1df21cd42e5f1c8bb24 *xorg-server-common-1.18.3-1.tar.xz ad87a7016ab70ca0814ed6152ab8f75c64f5db5c956c39f2e8c8ff24b94ee88c8956d750c782f805441764ea0f674171d61a9392c4c26667ce376d27ee9233c8 *xorg-server-debuginfo-1.18.3-1.tar.xz 44f9bc0159cfb124264b088162b21a7f860233ea82a3e5605f0c9edf80c4f084ccdb4cfeb4c8f35936bd39dbfc214ff329cf4d106a655cfbcdca675aa00d7a3e *xorg-server-devel-1.18.3-1.tar.xz 8763ff1b114229e42145848af73695499adb89b1987563393046be4af456d75052c09a7b8e0b079690fb3ac1ed69256ab8c75a23701b33177f9c06a19994e716 *xorg-server-dmx-1.18.3-1.tar.xz a87e3dc6f45bf5f9f7a7386f264019b2a600655aa7eefe2fa2556b7b38e85fb7ad588d84d71e75079abfeac9f18192ae57695758dd2ea4d165fe0a58f8c814ac *xorg-server-extra-1.18.3-1.tar.xz 6d47f0531adb1e5f3f05f6a4c557e5ab8c0191c89666267cb5796562d9a383f079289ad234b0340132c0c947bb3e7bcec5458136e0491d71d293cd3d5945d86f *xwinclip-1.18.3-1.tar.xz -- 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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
Marco Atzeri writes: > what is the content of > cmake_link_script > CMakeFiles/cmTC_5d15a.dir/link.txt None of these files exists after the failed cmake exits. The directory ./CMakeFiles/CMakeTmp is created, but it's empty. The entire directory structure that is remaining after executing "cmake ." is attached to my previous post as cmaketest64.zip. -- Frank -- 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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
Am 21.06.2016 um 03:43 schrieb Frank Brill: I am having trouble building an open source project using cmake under Cygwin64 with the latest tools (setup-x86_64.exe version 2.874). Well, FWIW, with the CMake-based projects I've been building here (Windows10 64-bit, Cygwin 64-bit, packages gcc 5.4.0-1, cmake 3.3.2-1, GNU make 4.2.1-1), it has worked just fine, and still does. I've built the current upstream release version of cmake itself with it, among quite a number of things. One possibly important difference is that you keep your source tree in the Windows user profile directory; I never subscribed to that idea. What this brings to mind is that maybe an antivirus program or other BLODA is getting in the way here. /usr/bin/cc -Wl,--enable-auto-import CMakeFiles/cmTC_5d15a.dir/testCCompiler.c.o -o cmTC_5d15a.exe -Wl,--out-implib,libcmTC_5d15a.dll.a -Wl,--major-image-version,0,--minor-image-version,0 The linker command looks pretty much exactly like the one that works around here. -- 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: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2
On Jun 20, 2016, at 10:53 PM, lloyd.w...@yahoo.co.uk wrote: > > Yes, it's the same piping problem of three years ago. …where you were asked to provide a simple test case for the problem, instead of “compile admittedly difficult-to-build package Geomview and use it against one of the most complicated packages in Cygwin, OpenGL.” Here’s what a simple test case looks like: $ dd if=/dev/urandom bs=4k count=4m | gpg -c --force-mdc | gpg -d > /dev/null Type the same passphrase three times: twice to verify it for encryption, and once for decryption. The fact that this runs without errors proves that Cygwin 64 is capable of reliably transporting 16 GiB of data through a pipe without corruption. Try it on your system. If it gives an error, it shows that the problem is system-specific, and thus possibly BLODA or some other platform issue. If not, then please explain how your problem differs from the demonstration here. Have you ruled out Cygwin’s OpenGL package, such as by running it over X11 to a remote system running a different implementation? -- 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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
Hans-Bernhard Bröker writes: > One possibly important difference is that you keep your source tree in the > Windows user profile directory; I never subscribed to that idea. I've put the source tree in a number of places with the same result. I'll try again at any location you suggest. > What this brings to mind is that maybe an antivirus program or other BLODA > is getting in the way here. This would explain why I'm having the same bad behavior on multiple PC's at work--they all have the same BLODA. But it's strange that 32-bit works and 64-bit doesn't, and that an older version of 64-bit Cygwin worked. I will try from my home PC to see what happens. I am also trying to send a message with a more complete package of the errors, but so far the mail server on one end or the other has rejected my attempts. Will keep trying. -- Frank -- 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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
Tony Kelman writes:
> I'm at a conference this week so really busy, but it sounds like I may
> need to update cmake to the latest version (which is overdue anyway)
> if something in the latest gcc is unhappy. Can you provide full
> reproduction steps, a source repo or tarball to download? Also looking
> into (and posting) the full content of the cmake error/output log
> files might provide more information about what the problem is
I made the world's smallest example, taken from the CMake tutorial.
There's a CMakeLists.txt that contains this:
cmake_minimum_required (VERSION 2.6)
project (Tutorial)
add_executable(Tutorial tutorial.cxx)
and a tutorial.cxx that contains this:
// A simple program that computes the square root of a number
#include
#include
#include
int main (int argc, char *argv[])
{
if (argc < 2)
{
fprintf(stdout,"Usage: %s number\n",argv[0]);
return 1;
}
double inputValue = atof(argv[1]);
double outputValue = sqrt(inputValue);
fprintf(stdout,"The square root of %g is %g\n",
inputValue, outputValue);
return 0;
}
Just create the two files above and do:
$ cmake .
$ make
$ ./Tutorial 2
On 32-bit Cygwin, it all works nicely as expected. But on my fresh 64-bit
installation, I get the " not able to compile a simple test program" message.
I think Hans-Bernhard's theory that there's some other app interfering is
probably correct, and it probably has something to do with my company's
security software.
I will post more information in subsequent posts that hopefully stay under
the "spam score threshold".
--
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: Cmake on cygwin64 fails with error "C compiler "/usr/bin/cc" is not able to compile a simple test program"
The attached zip file contains the results when I create a directory called cmaketest64, put the two files from my previous post (CMakeLists.txt and tutorial.cxx) in it, and type "cmake ." I had to change the file extension from .zip to .z__ and remove two .exe files to get past the spam filters: cmaketest64/CMakeFiles/3.3.2/CompilerIdC/a.exe cmaketest64/CMakeFiles/3.3.2/CompilerIdCXX/a.exe cmaketest64.z__ Description: cmaketest64.z__ -- 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: Piping on 64-bit Cygwin, STC found
On Jun 21, 2016, at 3:57 PM, Warren Young wrote: > > Here’s what a simple test case looks like: > > $ dd if=/dev/urandom bs=4k count=4m | >gpg -c --force-mdc | >gpg -d > /dev/null I seem to have stumbled upon the actual STC. Just increase those values, launch two MinTTY terminals, and try to use Cygwin in the second while the GPG pipeline is running. All will be well for a while, but eventually the second window will start to behave strangely. I used 64k and 64M (capitalization is important to dd), and the failure I observed is that “man” commands wouldn’t always return you to the shell properly after exiting from the piped-to less process. Some kind of memory leak, perhaps? -- 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: Piping on 64-bit Cygwin, STC found
On Jun 21, 2016, at 4:40 PM, Warren Young wrote: > > On Jun 21, 2016, at 3:57 PM, Warren Young wrote: >> >> Here’s what a simple test case looks like: >> >> $ dd if=/dev/urandom bs=4k count=4m | >> gpg -c --force-mdc | >> gpg -d > /dev/null > > I seem to have stumbled upon the actual STC. Here’s a screen shot of the error the second MinTTY gives on trying to exit: https://imgur.com/5RLi4ie The “man bash” is the command I tried to give, and the “vi” command never executed, even after closing the first MinTTY window. The defunct “less” process is of course a child of the “man” process. > Just increase those values...I used 64k and 64M To be clear, I mean bs=64k count=64M, for 4 TiB of transfer. This ran for about half an hour before it started causing problems in the other MinTTY window here. I didn’t write down the amount transferred at that time, unfortunately, though dd did report it. Almost certainly many times more than available RAM at any rate. -- 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: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2
Warren, this piping problem on 64-bit Cygwin between Geomview and its modules (of which SaVi is the most used example) is entirely unrelated to OpenGL, and exists when Geomview is compiled without OpenGL. Three years ago, 64-bit OpenGL not yet working at all was simply motivation to see how the then-new 64-bit Geomview fleshed out. Intermittent problems with 32-bit OpenGL crashing are more motivation to get this piping issue fixed, as is the fact that 64-bit anything is the future. I hope that's clear. I don't have the technical knowledge to reduce Geomview's internal complexities to a simple C program doing piping to reproduce this piping problem, which is what is being asked for. Geomview IS the test case. Your piping-works-in-general example is unrelated to this. I've reproduced this SaVi-can't-talk-with-Geomview-on-64-bit-cygwin problem on multiple installs on multiple machines over the past three years, both Windows 10 and Windows 7, and have it on two Windows 10 machines and a Windows 7 machine right now. Yes, that is six Cygwin installs, each machine both 32 and 64-bit. Yes, Geomview is complex to install, which is why I maintain http://sat-net.com/L.Wood/software/SaVi/building-under-Windows/ updating those instructions every so often requires destroying and recreating Cygwin installs from scratch to see what the current required packages are, or have been renamed to, through trial and error, taking most of a workday. Which is why I have multiple installs on multiple machines. Having Geomview as a Cygwin package would be great by comparison. regards Lloyd Wood http://savi.sf.net/ (you might want to turn off non-ascii apostrophes. They don't seem to match your encoding, as shown in the web mailarchive.) Warren Young writes: On Jun 20, 2016, at 10:53 PM, lloyd.w...@yahoo.co.uk wrote: > > Yes, it's the same piping problem of three years ago. where you were asked to provide a simple test case for the problem, instead of compile admittedly difficult-to-build package Geomview and use it against one of the most complicated packages in Cygwin, OpenGL. Here's what a simple test case looks like: $ dd if=/dev/urandom bs=4k count=4m | gpg -c --force-mdc | gpg -d > /dev/null Type the same passphrase three times: twice to verify it for encryption, and once for decryption. The fact that this runs without errors proves that Cygwin 64 is capable of reliably transporting 16 GiB of data through a pipe without corruption. Try it on your system. If it gives an error, it shows that the problem is system-specific, and thus possibly BLODA or some other platform issue. If not, then please explain how your problem differs from the demonstration here. Have you ruled out Cygwin's OpenGL package, such as by running it over X11 to a remote system running a different implementation? -- 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: expat-2.2.0-1
Version 2.2.0-1 of expat has been uploaded. Expat is a stream-based XML parsing library used by many programs. This release tracks an upstream release, which is mainly a bugfix and security rollup release. All users of Expat 2.x should upgrade to it. *** 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. -- 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: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2
On Jun 21, 2016, at 4:54 PM, wrote: > > Three years ago, 64-bit OpenGL not yet working at all was simply motivation > to see how the then-new 64-bit Geomview fleshed out. Why mention OpenGL at all, then? This is part of reducing the problem to a simple test case: remove confounding complexities. > I don't have the technical knowledge to reduce Geomview's internal > complexities to a simple C program It doesn’t have to be a C program. It just has to be a short command or program that someone could run. Give me a 3-line command, or a short script, or a series of menu options to click, or *something*. Help me help you. > I've reproduced this SaVi-can't-talk-with-Geomview-on-64-bit-cygwin problem > on multiple installs How, exactly? Give me the step-by-step. Realize that almost no one reading this will even know what Geomview and SaVi *are*, much less how to run them. > (you might want to turn off non-ascii apostrophes. They don't seem to match > your encoding, as shown in the web mailarchive.) I just checked the archives of two other mailing lists I regularly contribute to, and they show the non-ASCII characters correctly in their web archives. My mailer is using good old UTF-8, as you can see by the headers it emits. Apparently Sourceware’s mail processing chain isn’t UTF-8 clean. -- 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: Piping on 64-bit Cygwin, STC found
Greetings, Warren Young! > I used 64k and 64M (capitalization is important to dd), You aren't confusing DD with some other tool? $ dd if=/dev/urandom of=/dev/null bs=64K count=1 1+0 records in 1+0 records out 65536 bytes (66 kB, 64 KiB) copied, 0,0183668 s, 3,6 MB/s $ dd if=/dev/urandom of=/dev/null bs=64k count=1 1+0 records in 1+0 records out 65536 bytes (66 kB, 64 KiB) copied, 0,00557431 s, 11,8 MB/s $ dd if=/dev/urandom of=/dev/null bs=64kb count=1 dd: invalid number: ‘64kb’ $ dd if=/dev/urandom of=/dev/null bs=64kB count=1 1+0 records in 1+0 records out 64000 bytes (64 kB, 62 KiB) copied, 0,00562949 s, 11,4 MB/s $ dd if=/dev/urandom of=/dev/null bs=64KB count=1 1+0 records in 1+0 records out 64000 bytes (64 kB, 62 KiB) copied, 0,00685924 s, 9,3 MB/s $ dd --version dd (coreutils) 8.25 Packaged by Cygwin (8.25-3) -- With best regards, Andrey Repin Wednesday, June 22, 2016 02:08:29 Sorry for my terrible english...
Re: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2
>>I've reproduced this SaVi-can't-talk-with-Geomview-on-64-bit-cygwin problem >>on multiple installs > How, exactly? Give me the step-by-step. Step by step instructions to build Geomview and SaVi are on: http://sat-net.com/L.Wood/software/SaVi/building-under-Windows/ launch with geomview -run ../savi1.4.9/savi build Geomview and SaVi on 32-bit and 64-bit Cygwin, and compare. On 32-bit Cygwin, SaVi talks to Geomview, you get a view of the Earth with a ring around it when you launch the two, you can control Geomview with SaVi and its menus as expected. On 64-bit, Geomview launched with SaVi: geomview -run ../savi1.4.9/savi gives a blank grey canvas window. Though SaVi may be listed as a module in Geomview's main window, clicking that does nothing. There is no piping communication between the applications. At all. Geomview is available from http://www.geomview.org/ SaVi is available from http://savi.sourceforge.net/ regards Lloyd Wood http://savi.sf.net -- 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: Piping on 64-bit Cygwin, STC found
On Jun 21, 2016, at 5:12 PM, Andrey Repin wrote: > > Greetings, Warren Young! > >> I used 64k and 64M (capitalization is important to dd), > > You aren't confusing DD with some other tool? Try testing with “M”, not “k”. Technically speaking, if it’s going to be picky about m vs M, it shouldn’t accept “K”, only “k”: https://en.wikipedia.org/wiki/Metric_prefix -- 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
