automatically using pipe_byte for certain EXE's

automatically using pipe_byte for certain EXE's

[Noel Grandin]

HI

I'm running into the pipe_byte problem while trying to use 
Visual-Studio's C compiler from inside cygwin.
I'm running latest cygwin (from a few days ago).

Specifically, I'm building LibreOffice on a 64-bit Windows7 box.

Is there any way to trigger the pipe_byte option for certain executables?
I'm trying to avoid having to dig around inside the hugely complex 
LibreOffice build scripts.

Thanks, Noel Grandin

--
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: automatically using pipe_byte for certain EXE's

[Daniel Colascione]

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

On 7/26/12 7:47 AM, Noel Grandin wrote:
> I'm running into the pipe_byte problem while trying to use
> Visual-Studio's C compiler from inside cygwin.
> I'm running latest cygwin (from a few days ago).
> 
> Specifically, I'm building LibreOffice on a 64-bit Windows7 box.
> 
> Is there any way to trigger the pipe_byte option for certain executables?
> I'm trying to avoid having to dig around inside the hugely complex
> LibreOffice build scripts.

I still don't know why anyone wouldn't want to use pipe_byte all the time.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

RE: automatically using pipe_byte for certain EXE's

[Adam Dinwoodie]

Daniel Colascione wrote:
> I still don't know why anyone wouldn't want to use pipe_byte all the time.

I think that was covered pretty explicitly by cgf in reply to you some time
ago:

http://cygwin.com/ml/cygwin/2012-04/msg00662.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: automatically using pipe_byte for certain EXE's

[Daniel Colascione]

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

On 7/26/12 9:34 AM, Adam Dinwoodie wrote:
> Daniel Colascione wrote:
>> I still don't know why anyone wouldn't want to use pipe_byte all the time.
> 
> I think that was covered pretty explicitly by cgf in reply to you some time
> ago:

Cygwin still uses message pipes for ptys in pipe_byte mode, so the
first of cgf's reasons doesn't apply. As for the way message pipes
"more closely mimic" Linux pipes: I don't see it. What's the
difference? And does it matter in practice? Can someone give me an
actual example of a problem caused by using byte pipes in the non-pty
case? I'm not aware of any.

Since message pipes cause problems _in practice_ and byte pipes (which
Cygwin lived with for many years) don't seem to cause problems _in
practice_, pipe_byte should go away and pipe_byte behavior should be
used unconditionally.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

RE: automatically using pipe_byte for certain EXE's

[Adam Dinwoodie]

Daniel Colascione wrote:
>Since message pipes cause problems _in practice_ and byte pipes (which
>Cygwin lived with for many years) don't seem to cause problems _in
>practice_, pipe_byte should go away and pipe_byte behavior should be
>used unconditionally.

The folk who develop and release cygwin1.dll have made it clear that they're
not going to do this, however much you ask. And since they're the folk who do
the development, it's their choice to make.

That DLL is released under the GPLv3. That means if you don't like what's being
given to you for free, you're able to change it to do what you want it to do.
Or, if you don't have the ability to change it yourself, you can pay someone to
do it for you.

Don't complain when the free car someone just gave you has road tires when you
need ones for dirt tracks. Don't keep complaining when the folk who just gave
you that free car say they don't want to change your tires for you. Either fix
the tires yourself, or find a garage that'll take your money and fit some
off-road tires for you.

--
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: automatically using pipe_byte for certain EXE's

[James Johnston]

> -----Original Message-----
> Sent: Friday, July 27, 2012 10:05
> Subject: RE: automatically using pipe_byte for certain EXE's
> 
> Daniel Colascione wrote:
> >Since message pipes cause problems _in practice_ and byte pipes (which
> >Cygwin lived with for many years) don't seem to cause problems _in
> >practice_, pipe_byte should go away and pipe_byte behavior should be
> >used unconditionally.
> 
> The folk who develop and release cygwin1.dll have made it clear that
they're
> not going to do this, however much you ask. And since they're the folk who
> do the development, it's their choice to make.
> 
> That DLL is released under the GPLv3. That means if you don't like what's
> being given to you for free, you're able to change it to do what you want
it to
> do.
> Or, if you don't have the ability to change it yourself, you can pay
someone to
> do it for you.
> 
> Don't complain when the free car someone just gave you has road tires
> when you need ones for dirt tracks. Don't keep complaining when the folk
> who just gave you that free car say they don't want to change your tires
for
> you. Either fix the tires yourself, or find a garage that'll take your
money and
> fit some off-road tires for you. 

Out of curiosity, I decided to look at the LibreOffice web site, since I
wasn't really believing that you actually *had* to use Cygwin to compile on
Windows.  I figured surely a project the size of LibreOffice wouldn't depend
on Cygwin, given its problems / lack of support of non-Cygwin programs,
unresolvable problems with fork, general dependency on undocumented Windows
data structures/behavior/APIs, paths that are not compatible with Windows
without using the cygpath utility, and now odd piping behavior.  Cygwin is a
fantastic tool to have around on my workstation for when I want a
POSIX/Linux-like environment for prototyping / general purpose use / use of
tools that don't have native Windows versions.  But now that I have learned
more about these issues with Cygwin, I probably wouldn't pick it for
something critical and I think the build environment is a critical thing -
maybe MSYS is more appropriate?  I figured surely the LibreOffice developers
would already have known all about this, but it turns out I was wrong and
they are using Cygwin...  Frankly I'm surprised there haven't been more
complaints about LibreOffice build issues up until now, given their heavy
reliance on non-Cygwin programs.  I'd be curious to look up what kind of
discussion may have transpired on the LibreOffice mailing last last few
months about build problems, but I'm too lazy.  (Or do they never update
their Cygwin to versions released in the last 9 months?)

I can certainly understand this user's frustration though... latest version
of LibreOffice is not building with latest version of Cygwin.  Dependency
incompatibilities because of version changes is one of those things that has
frustrated me in the past on Linux when trying to compile something from
source.  Maybe someone on the LibreOffice mailing list would be more willing
to investigate and fix Cygwin and/or its packages, since it is apparently
used in their core build process?  I would hope that, between the two
projects, there is a developer actually interested in making sure that
things generally build and work right ("smoke testing") and not leave it to
the end users / total beginner developers to the project.

</rant>

References:

http://wiki.documentfoundation.org/Development/BuildingOnWindowsWithCygwinAn
dMSVCExpress
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies



--
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: automatically using pipe_byte for certain EXE's

[Adam Dinwoodie]

Noel Grandin wrote:
>Is there any way to trigger the pipe_byte option for certain executables?
>I'm trying to avoid having to dig around inside the hugely complex-
>LibreOffice build scripts.

I'm not sure I follow what you're after. You want Cygwin to recognize when it's
setting up a pipe involving a specific executable, and to set that up as if it
were using byte pipes rather than message pipes?

I would imagine that would be difficult-to-impossible, for the same reason as
trying to work out whether an executable links into cygwin1.dll. See cgf's
explanation here: http://cygwin.com/ml/cygwin/2012-05/msg00192.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: automatically using pipe_byte for certain EXE's

[Noel Grandin]

On 2012-07-26 20:23, Adam Dinwoodie wrote:
> Noel Grandin wrote:
>> Is there any way to trigger the pipe_byte option for certain executables?
>> I'm trying to avoid having to dig around inside the hugely complex-
>> LibreOffice build scripts.
> I'm not sure I follow what you're after. You want Cygwin to recognize when it's
> setting up a pipe involving a specific executable, and to set that up as if it
> were using byte pipes rather than message pipes?
>
>

Basically, the problem I'm seeing is that the cl.exe (the visual C 
command line compiler) is occasionally stalling when being driven from 
the LibreOffice makefiles.
It appears that one of the ends of the pipe is waiting on something.
Setting the pipe_byte flag seems to help with the cl.exe, but it causes 
other weird issues elsewhere.


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