Re: [gentoo-alt] multilib / multijob / parallel build problem

[Greg Turner]

On Sat, Oct 5, 2013 at 4:16 PM, Alan Hourihane <alanh@×××××××××××.uk> wrote:
> No it's not cygwin, and as I said I already googled it.

Trust me, at the end of the day, it's a cygwin bug.  Technically
speaking, Cygwin supports bidi pipes with the same semantics as Linux,
but the implementation is broken.  IIRC, something as simple as "diff
-u <(echo 1) <(echo 2)" in cygwin bash is enough to confirm that.

> But I will say the current mechanism is not POSIX compliant. Gentoo is using
> a Linux'ism here and it's not portable. Opening a fifo in read/write mode
> has nondeterministic behavior in POSIX.
>
> Should I log this as a bug ?

That's an good point, and you certainly /could/ file a bug for that.
But unless you have a POSIX compliant drop-in replacement ready to go,
I think your bug is likely to be met with a pretty cool reception.  In
fact I'm pretty sure I already filed a bug and the response I got was
along the lines of "add a stub implementation and a platform blacklist
with just cygwin in it, if you like."

From a theoretical perspective, I guess Gentoo has no POSIX compliance
policy, in which case, there really is no bug to be fixed.

Fixing the implementation to be truly POSIX is probably do-able.
Fixing Cygwin's named pipe implementation also didn't look
insurmountable.  So after some quick experimentation to see if I could
figure out a quick-and-dirty solution (I couldn't), I kind of put it
on my long-term todo list where it's remained since.

The stubs work, though, to solve the problem, at a
tolerable-if-unfortunate cost of making cygwin portage slower.   Also
there is code in my cygwin overlay on github that, although
theoretically not a correct solution (IIRC because it is not atomic in
some crucial places), works pretty good.

Do be sure to fix it in the portage code and in the eclass, if you are
fixing it -- the code is almost identical, so this is easy, but unless
you fix both, it won't help.

-gmt