Re: [ANNOUNCEMENT] llvm 3.7.1-2

Re: [ANNOUNCEMENT] llvm 3.7.1-2

[lloyd.wood]

Thanks, picking up 3.7.1-2 from the mirrors.kernel.org site (as it's not mirrored everywhere yet) resolved the 32-bit OpenGL crashing issues with SaVi and Geomview that I reported in May; texturemapping is back.

(I've no idea how 64-bit OpenGL is doing, as unique Cygwin piping issues there prevent SaVi and Geomview from communicating.)

regards

Lloyd Wood
http://savi.sf.net


***
The following packages have been uploaded to the Cygwin distribution: * llvm-3.7.1-2
* llvm-doc-3.7.1-2
* libllvm3.7-3.7.1-2
* libllvm-devel-3.7.1-2 The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation. This release includes a backport and fix for RuntimeDyldCOFFI386 from Jon Turney in order to fix OpenGL software rendering on 32-bit Cygwin.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] llvm 3.7.1-2

[Yaakov Selkowitz]

On 6/9/2016 8:18 PM, lloyd.wood@yahoo.co.uk wrote:
> Thanks, picking up 3.7.1-2 from the mirrors.kernel.org site (as it's
> not mirrored everywhere yet) resolved the 32-bit OpenGL crashing issues
> with SaVi and Geomview that I reported in May; texturemapping is back.

Glad to hear it.

> (I've no idea how 64-bit OpenGL is doing, as unique Cygwin piping issues
> there prevent SaVi and Geomview from communicating.)

64-bit was fine all along; that's what I actually use, so I would have 
noticed earlier if it hadn't been working.

-- 
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: [ANNOUNCEMENT] llvm 3.7.1-2

[Jon Turney]

On 10/06/2016 02:18, lloyd.wood@yahoo.co.uk wrote:
> Thanks, picking up 3.7.1-2 from the mirrors.kernel.org site (as it's
> not mirrored everywhere yet) resolved the 32-bit OpenGL crashing
> issues with SaVi and Geomview that I reported in May; texturemapping
> is back.

You're welcome.

> (I've no idea how 64-bit OpenGL is doing, as unique Cygwin piping
> issues there prevent SaVi and Geomview from communicating.)

I guess this is the same 'piping problem' I asked for more details on 
back in [1]?

Can you please provide more information?

[1] https://cygwin.com/ml/cygwin/2013-07/msg00675.html

-- 
Jon Turney
Volunteer Cygwin/X X Server maintainer

--
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

Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[lloyd.wood]

Yes, it's the same piping problem of three years ago.

At the time the Geomview community wondered if this was
the shape of things to come for piping and IPC in general,
and if Geomview would need fixing for all platforms.
But since 32-bit and 64-bit Cygwin differed, and OpenGL
didn't work on 64-bit Cygwin either, making 32-bit the
obvious choice to use, masterful inaction was the
result. Wait and see how 64-bit Cygwin shakes out...


Three years on, 64-bit Cygwin is still the outlier;
piping works everywhere else, 32- and 64-bit. It would
be good to have 64-bit Cygwin work with Geomview and
its modules, particularly since 32-bit OpenGL seems less
than reliable (as also shown by the weird things seen
on Raspbian on the Pi).


It would also be good if Geomview was in the Cygwin
installer, as compiling it is not easy for many; it's
already a Debian package.


But I don't personally have the technical piping or
Cygwin-specific knowledge to troubleshoot this one,
other than providing and maintaining the installation
hints at


http://sat-net.com/L.Wood/software/SaVi/building-under-Windows/

thanks

Lloyd Wood
http://savi.sf.net/
(that screenshot comes from 32-bit Cygwin, btw.) 


----- Original Message -----
From: Jon Turney <jon.turney@dronecode.org.uk>
To: cygwin@cygwin.com
Cc: lloyd.wood@yahoo.co.uk
Sent: Monday, 20 June 2016, 22:58
Subject: Re: [ANNOUNCEMENT] llvm 3.7.1-2

On 10/06/2016 02:18, lloyd.wood@yahoo.co.uk wrote:
> Thanks, picking up 3.7.1-2 from the mirrors.kernel.org site (as it's
> not mirrored everywhere yet) resolved the 32-bit OpenGL crashing
> issues with SaVi and Geomview that I reported in May; texturemapping
> is back.

You're welcome.

> (I've no idea how 64-bit OpenGL is doing, as unique Cygwin piping
> issues there prevent SaVi and Geomview from communicating.)

I guess this is the same 'piping problem' I asked for more details on 
back in [1]?

Can you please provide more information?

[1] https://cygwin.com/ml/cygwin/2013-07/msg00675.html


-- 
Jon Turney
Volunteer Cygwin/X X Server maintainer

--
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 Young]

On Jun 20, 2016, at 10:53 PM, lloyd.wood@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: Piping on 64-bit Cygwin, STC found

[Warren Young]

On Jun 21, 2016, at 3:57 PM, Warren Young <wyml@etr-usa.com> 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

[Warren Young]

On Jun 21, 2016, at 4:40 PM, Warren Young <wyml@etr-usa.com> wrote:
> 
> On Jun 21, 2016, at 3:57 PM, Warren Young <wyml@etr-usa.com> 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, STC found

[Andrey Repin]

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, STC found

[Warren Young]

On Jun 21, 2016, at 5:12 PM, Andrey Repin <anrdaemon@yandex.ru> 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

Re: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

On Jun 23 17:05, cyg Simple wrote:
> On 6/22/2016 1:17 PM, Corinna Vinschen wrote:
> > On Jun 22 10:01, Warren Young wrote: 
> >> Still, you could get similar problems.  ifdefs for portable
> >> sized-integer types are a particularly rich source of bugs, especially
> >> ones where #ifdef WINDOWS precedes any test that could match Cygwin,
> >> since WINDOWS is defined in Cygwin’s GCC, and as this exchange shows,
> > 
> > No, it isn't.  Neither is _WIN32 or _WINNT_, unless you include
> > <windows.h>.  Try `gcc -dM -E - < /dev/null | grep WIN'
> > 
> 
> IIRC early versions (2.8, 3.x) of Cygwin GCC did but it hasn't for some
> time.  I forget when it changed.

If so, it was long, long, ago.  AFAIR _WIN32 was only defined if you
included windows.h, even back in Cygwin 1.5 times.  Or even 1.3.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[cyg Simple]

On 6/22/2016 1:17 PM, Corinna Vinschen wrote:
> On Jun 22 10:01, Warren Young wrote: 
>> Still, you could get similar problems.  ifdefs for portable
>> sized-integer types are a particularly rich source of bugs, especially
>> ones where #ifdef WINDOWS precedes any test that could match Cygwin,
>> since WINDOWS is defined in Cygwin’s GCC, and as this exchange shows,
> 
> No, it isn't.  Neither is _WIN32 or _WINNT_, unless you include
> <windows.h>.  Try `gcc -dM -E - < /dev/null | grep WIN'
> 

IIRC early versions (2.8, 3.x) of Cygwin GCC did but it hasn't for some
time.  I forget when it changed.

-- 
cyg 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: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

On Jun 22 10:01, Warren Young wrote:
> On Jun 22, 2016, at 9:36 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > 
> >> 64-bit Windows is LLP64, while 64-bit Linux is LP64 on the same hardware.
> > 
> > s/Linux/Linux and Cygwin/
> 
> Well, that was unexpected.

The FAQ entry is just as old as the first 64 bit release...

> Still, you could get similar problems.  ifdefs for portable
> sized-integer types are a particularly rich source of bugs, especially
> ones where #ifdef WINDOWS precedes any test that could match Cygwin,
> since WINDOWS is defined in Cygwin’s GCC, and as this exchange shows,

No, it isn't.  Neither is _WIN32 or _WINNT_, unless you include
<windows.h>.  Try `gcc -dM -E - < /dev/null | grep WIN'

> Cygwin’s GCC doesn’t always behave exactly the same as Visual C++.
> 
> Any such case will compile under Cygwin.  You need to reorder such
> cases so a the test for WINDOWS is after one matching Cygwin, as a
> rule.

Varargs functions are fun.  A type mismatch int/long in the 5th and 6th
arg would be invisible on Linux but potentially crash on Cygwin due to
the ABI difference (MS vs. SysV).  We found a bug in OpenLDAP this way.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[Warren Young]

On Jun 22, 2016, at 9:36 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
>> 64-bit Windows is LLP64, while 64-bit Linux is LP64 on the same hardware.
> 
> s/Linux/Linux and Cygwin/

Well, that was unexpected.

Still, you could get similar problems.  ifdefs for portable sized-integer types are a particularly rich source of bugs, especially ones where #ifdef WINDOWS precedes any test that could match Cygwin, since WINDOWS is defined in Cygwin’s GCC, and as this exchange shows, Cygwin’s GCC doesn’t always behave exactly the same as Visual C++.

Any such case will compile under Cygwin.  You need to reorder such cases so a the test for WINDOWS is after one matching Cygwin, as a rule.
--
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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

On Jun 22 09:29, Warren Young wrote:
> On Jun 22, 2016, at 6:39 AM, Marco Atzeri <marco.atzeri@gmail.com> wrote:
> > 
> > 
> > may be is a piping problem, but there is no evidence; it could be a lot of different issues due to 64bit porting.
> > I will not be surprise if there is wrong assumption on data size.
> 
> That’s my guess, too.
> 
> 64-bit Windows is LLP64, while 64-bit Linux is LP64 on the same hardware.

s/Linux/Linux and Cygwin/

> That means that any binary protocol that uses C’s “long” data type
> will do the wrong thing on Cygwin, because it uses Windows’ data size
> rules for ABI compatibility with Windows.
> 
> See https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

And https://cygwin.com/faq.html#faq.programming.64bitporting


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[Warren Young]

On Jun 22, 2016, at 6:39 AM, Marco Atzeri <marco.atzeri@gmail.com> wrote:
> 
> 
> may be is a piping problem, but there is no evidence; it could be a lot of different issues due to 64bit porting.
> I will not be surprise if there is wrong assumption on data size.

That’s my guess, too.

64-bit Windows is LLP64, while 64-bit Linux is LP64 on the same hardware.

That means that any binary protocol that uses C’s “long” data type will do the wrong thing on Cygwin, because it uses Windows’ data size rules for ABI compatibility with Windows.

See https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
--
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

[Marco Atzeri]

On 22/06/2016 03:32, lloyd.wood@yahoo.co.uk wrote:
>
>>> 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.

may be is a piping problem, but there is no evidence; it could be a lot 
of different issues due to 64bit porting.
I will not be surprise if there is wrong assumption on data size.

>
> Geomview is available from http://www.geomview.org/
> SaVi is available from http://savi.sourceforge.net/
>
> regards
>
> Lloyd Wood
> http://savi.sf.net

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: Piping on 64-bit Cygwin was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[lloyd.wood]

>>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 was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[Warren Young]

On Jun 21, 2016, at 4:54 PM, <lloyd.wood@yahoo.co.uk> <lloyd.wood@yahoo.co.uk> 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 was Re: [ANNOUNCEMENT] llvm 3.7.1-2

[lloyd.wood]

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.wood@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