[PATCH libtirpc] Disable libtirpc's own bindresvport{,_sa}() in favor of Cygwin's

[Mark Geisert]

I don't have libtirpc in git so I'm submitting a text patch.  Sorry for any 
inconvenience.  This is Cygwin-specific and against src/bindresvport.c of 
libtirpc 1.0.1.  Unsure if it ought to go upstream; appreciate input on that.

Thanks much,

..mark

8<
35a36,38
> /* On Cygwin prefer Cygwin's bindresvport{,_sa}() to portable version here */
> #if !defined(__CYGWIN__)
>
247a251,252
>
> #endif /* !defined(__CYGWIN__) */

Re: RPC clnt_create() adress already in use

[Mark Geisert]

Corinna Vinschen wrote:

On Feb  6 11:29, PAULUS, Raimund, TI-ABN wrote:

On Feb  5 15:06, Corinna Vinschen wrote:

[...]

I've pushed a few patches and uploaded new developer snapshots to
https://cygwin.com/snapshots.  Please give them a try.

with the snapshot of cygwin1.dll and using bindresvport() from Cygwin
for libtirpc (instead of the original bindresvport() from libtirpc)
all my testcases work without error.

Many thanks
Raimund


Thanks for testing.  Please note that this should work most of the time,
but is still not 100% foolproof.  There's a systematic race between
checking existing connections and calling bind which can't be easily
worked around by Cygwin.  Still, should be better than before :}


Great to read this latest status.  I'll shortly submit a libtirpc patch to stub 
out its own version of bindresvport() in favor of Cygwin's version.

Thanks all,

..mark

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

Ghostscript cannot find CMaps in Poppler

[Vonobow Smith]

 From Cygwin which is bundled with Ghostscript 9.21,
Ghostscript cannot find CMap's at all. As a result, CJK characters 
cannot be rendered at all.

> $ gsnd
> GPL Ghostscript 9.22 (2017-10-04)
> Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> GS>/UniJIS-UTF8-H /CMap findresource
> Error: /undefinedresource in findresource

This is caused by incorrect setting of search path for Ghostscript,
or the directory hierarchy of Poppler.

 GS search path is set as following:

$ gs --help
> GPL Ghostscript 9.22 (2017-10-04)
> Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
> Usage: gs [switches] [file1.ps file2.ps ...]
... snip ...
> Search path:
>/usr/share/ghostscript/9.22/Resource/Init :
>/usr/share/ghostscript/9.22/lib :
>/usr/share/ghostscript/9.22/Resource/Font :
>/usr/share/ghostscript/fonts : /usr/share/fonts/urw-base35 :
>/usr/share/fonts : /usr/share/poppler/cMap/Adobe-CNS1 :
>/usr/share/poppler/cMap/Adobe-GB1 :
>/usr/share/poppler/cMap/Adobe-Japan1 :
>/usr/share/poppler/cMap/Adobe-Japan2 :
>/usr/share/poppler/cMap/Adobe-Korea1

However, CMap files are placed at:
> $ cd /usr/share/poppler/cMap/Adobe-Japan1/; ls
> 78-EUC-HAdobe-Japan1-H-CID   UniHojo-UTF32-H
> 78-EUC-VAdobe-Japan1-H-Host  UniHojo-UTF32-V
> 78-HAdobe-Japan1-H-Mac   UniHojo-UTF8-H
... snip ...

The problem is directory hierachy lacks the element "CMap".
CMap files must be found in CMap directory under the search path, like:

/usr/share/poppler/cMap/Adobe-Japan1/CMap/UniJIS-UTF8-H
 
The old version of the Ghostscript held CMap's under:

/usr/share/ghostscript/ver.sion/Resources/CMap

and this is correct.

The easiest way to solve this problem is creating symbolic links
which name is "CMap" in each directories containing CMap files,
target of the links are the directories itself, like that:

cd /usr/share/poppler/cMap; for i in *; do (cd $i; ln -s . CMap); done

Sorry if it is alread reported. Best Regards.


cygcheck.tar.gz
Description: application/gzip

--
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.887 release candidate - please test

[Steven Penny]

On Tue, 6 Feb 2018 15:04:49, Jon Turney wrote:

- Query the user for action to take if a corrupt local file is found


works great - thanks

- 'Current' is replaced by 'Best' (which is slightly different in ways 
it's difficult to summarize briefly) and 'Sync' (which exposes the 
--force-current (distupgrade) option through the UI).


i get the desire for one word labels - but im not sure how good "sync" is. its
not clear in the GUI what it does, and frankly, even reading your description
doesnt clear up for me what it does. i guess i would need to run "--help" and
see what "--force-current" does to figure it out. that just seems like more work
than it should be.

another long time nitpick i have had - to choose between the different package
versions you simply click the version - however i have never liked this because
it loops through the different versions. so if you forgot the first version you
looked at then you end up looping repeatedly. i think a drop down with the
different version numbers would be better - as you could see all versions at
once and choose what you like

i understand my suggest will prob be ignored as i do not have a patch - but i
wanted to put it out there - thanks again


--
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: libpaper-common-1.1.24-2 download errors

[Steven Penny]

On Tue, 6 Feb 2018 15:42:11, John Zastrow wrote:

Hello I'm trying to install Imagemagick using 64-bit cygwin on Win10. I'm
using Cygwin version 2.10.0
 to update an
earlier version. All works well, except the dependency
package libpaper-common-1.1.24-2 reports download errors from 5 eastern USA
mirrors. All other packages download fine.


Looks ok here:

   q=x86_64/release/libpaper/libpaper-common/libpaper-common-1.1.24-2.tar.bz2
   while read v
   do curl -Is "$v"/"$q" | head -1
   done 

[PATCH cygport] Produce obsoletes: headers in .hint files

[Jon Turney]

Signed-off-by: Jon Turney 
---
 lib/pkg_pkg.cygpart | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 0dba03d..aa6f0e8 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -718,6 +718,11 @@ requires: ${pkg_bin_requires} ${!pkg_requires_var}
 sdesc: "${!pkg_summary_var:-${SUMMARY}}"
 ldesc: 
"${!pkg_description_var:-${DESCRIPTION:-${!pkg_summary_var:-${SUMMARY"
 _EOF
+   if [ -n "${!pkg_obsoletes_var}" ]
+   then
+   cat >> 
${distdir}/${PN}/${distsubdir}/${pkg_name[${n}]}-${PVR}.hint <<-_EOF
+obsoletes: ${!pkg_obsoletes_var}
+   fi
if defined distsubdir
then
cat >> 
${distdir}/${PN}/${distsubdir}/${pkg_name[${n}]}-${PVR}.hint <<-_EOF
@@ -788,6 +793,11 @@ ldesc: "This package contains files necessary for 
debugging the
 ${PN} package with gdb."
 ${pkg_tag}
 _EOF
+   if [ -n "${!dbg_obsoletes_var}" ]
+   then
+   cat >> 
${distdir}/${PN}/${PN}-debuginfo/${PN}-debuginfo-${PVR}.hint <<-_EOF
+obsoletes: ${!dbg_obsoletes_var}
+   fi
fi
 
for obspkg in ${!dbg_obsoletes_var}
-- 
2.16.1

Re: [ANNOUNCEMENT] Updated: mintty 2.8.4 {GOLDSTAR]

[Thomas Wolff]

Am 06.02.2018 um 16:45 schrieb Andrew Schulman:

On 2018-02-05 21:45, Yaakov Selkowitz wrote:

On 2018-02-05 20:01, Andrew Schulman wrote:

I have uploaded mintty 2.8.4 with the following changes:

I'll just take this opportunity to say thanks for maintaining this really
central application in Cygwin. I use it every day to get my work done. Andrew

Then let's do something about it. :-D

He should be severely castigated for his prescient behaviour of adding new
features and fixing problems before we can report them. Should we pin an old
guy's Gold Watch on him, give him five Golden Rings^WStars so long after Xmas,
or do his mintty actions deserve the most extreme treatment, [Oh, no! *NOT*...]
the (Pink) Plush Hippo?

Awarded! http://cygwin.com/goldstars/#TW

BTW it's Known that 3 gold stars equals one plush hippo.

Andrew
The cute hippo is much appreciated and I'm listing the award on my 
professional profile pages.

Thanks
Thomas

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

libpaper-common-1.1.24-2 download errors

[John Zastrow]

Hello I'm trying to install Imagemagick using 64-bit cygwin on Win10. I'm
using Cygwin version 2.10.0
 to update an
earlier version. All works well, except the dependency
package libpaper-common-1.1.24-2 reports download errors from 5 eastern USA
mirrors. All other packages download fine.

Please help.
John

--
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: vim-8.0.1376-1: Possible bug with ruby extensions

[Brian Inglis]

On 2018-02-06 09:37, Ameya Vikram Singh wrote:
> Maintainers of the ViM/GViM text editor.
> I am noticing that currently with the latest build of ViM
> editor(vim-8.0.1376-1),
> I am unable to use the command-t [1] plugin with this release.
> When invoking the functionality with the key combination: `\` + `t`
> I get the following error message on the ViM editor:
> command-t.vim requires Vim to be compiled with Ruby support
> For more information type:   :help command-t
> When checking the vim feature from the bash terminal using:
> vim --version
> I do see in the output `+ruby/dyn`, which means that ruby support
> should be enabled.
> When checking for ruby compatibility with ViM using the following in
> command mode:
> :ruby puts RUBY_VERSION
> One gets the following error message:
> E448: Could not load library function rb_assoc_new
> E266: Sorry, this command is disabled, the Ruby library could not be 
> loaded.
> Press ENTER or type command to continue
> I will try to rebuild the from the sources (vim-8.0.1376-1-src) and
> see if the error persists.

You need to install the ruby package to provide the dynamic library for support.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: OpenBLAS patch for Cygwin

[Achim Gratz]

Erik Bray writes:
> Assuming this looks good (feedback welcome) it might be nice to have
> this patch included in the next release of the official OpenBLAS
> package for Cygwin since its incompatibility with fork() has caused
> problems in the past [1].

It would be vastly preferrable if OPenBLAS ditched the (unfortunately
quite common) notion that "Cygwin is some sort of Windows" for "Cygwin
is some sort of Linux".  I've patched out quite some bit of conditionals
like that in some other packages and it was almost always for the
better.  The worst ones are those that go into the Windows conditional
branch and then on to "oh wait, but for Cygwin we need something else".


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

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

[newlib-cygwin] Cygwin: setsockopt/getsockopt: Clean up code

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=f8ce6912231d929d225c4ac428b790b1570e5175

commit f8ce6912231d929d225c4ac428b790b1570e5175
Author: Corinna Vinschen 
Date:   Tue Feb 6 18:42:00 2018 +0100

Cygwin: setsockopt/getsockopt: Clean up code

Rearrange setsockopt/getsockopt into per level/per optname
preprocessing switch, actual call,  per level/per optname
postprocessing switch for better readability as well as
extensibility.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/net.cc | 325 ---
 1 file changed, 207 insertions(+), 118 deletions(-)

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index 3fadb2b..9ff64b8 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -797,6 +797,7 @@ extern "C" int
 cygwin_setsockopt (int fd, int level, int optname, const void *optval,
   socklen_t optlen)
 {
+  bool ignore = false;
   int res = -1;
 
   __try
@@ -805,105 +806,130 @@ cygwin_setsockopt (int fd, int level, int optname, 
const void *optval,
   if (!fh)
__leave;
 
-  /* Switch off the AF_LOCAL handshake and thus SO_PEERCRED handling
-for AF_LOCAL/SOCK_STREAM sockets.  This allows to handle special
-situations in which connect is called before a listening socket
-accepts connections.
-FIXME: In the long run we should find a more generic solution which
-doesn't require a blocking handshake in accept/connect to exchange
-SO_PEERCRED credentials. */
-  if (level == SOL_SOCKET && optname == SO_PEERCRED)
-   {
- if (optval || optlen)
-   set_errno (EINVAL);
- else
-   res = fh->af_local_set_no_getpeereid ();
- __leave;
+  /* Preprocessing setsockopt.  Set ignore to true if setsockopt call
+should get skipped entirely. */
+  switch (level)
+   {
+   case SOL_SOCKET:
+ switch (optname)
+   {
+   case SO_PEERCRED:
+ /* Switch off the AF_LOCAL handshake and thus SO_PEERCRED
+handling for AF_LOCAL/SOCK_STREAM sockets.  This allows to
+handle special situations in which connect is called before
+a listening socket accepts connections.
+FIXME: In the long run we should find a more generic solution
+which doesn't require a blocking handshake in accept/connect
+to exchange SO_PEERCRED credentials. */
+ if (optval || optlen)
+   set_errno (EINVAL);
+ else
+   res = fh->af_local_set_no_getpeereid ();
+ __leave;
+
+   case SO_REUSEADDR:
+ /* Per POSIX we must not be able to reuse a complete duplicate
+of a local TCP address (same IP, same port), even if
+SO_REUSEADDR has been set.  This behaviour is maintained in
+WinSock for backward compatibility, while the WinSock
+standard behaviour of stream socket binding is equivalent to
+the POSIX behaviour as if SO_REUSEADDR has been set.
+The SO_EXCLUSIVEADDRUSE option has been added to allow an
+application to request POSIX standard behaviour in the
+non-SO_REUSEADDR case.
+
+To emulate POSIX socket binding behaviour, note that
+SO_REUSEADDR has been set but don't call setsockopt.
+Instead fhandler_socket::bind sets SO_EXCLUSIVEADDRUSE if
+the application did not set SO_REUSEADDR. */
+ if (fh->get_socket_type () == SOCK_STREAM)
+   ignore = true;
+ break;
+
+   default:
+ break;
+   }
+ break;
+
+   case IPPROTO_IP:
+ /* Old applications still use the old WinSock1 IPPROTO_IP values. */
+ if (CYGWIN_VERSION_CHECK_FOR_USING_WINSOCK1_VALUES)
+   optname = convert_ws1_ip_optname (optname);
+ switch (optname)
+   {
+   case IP_TOS:
+ /* Winsock doesn't support setting the IP_TOS field with
+setsockopt and TOS was never implemented for TCP anyway.
+setsockopt returns WinSock error 10022, WSAEINVAL when
+trying to set the IP_TOS field.  We just return 0 instead. */
+ ignore = true;
+ break;
+
+   default:
+ break;
+   }
+ break;
+
+   case IPPROTO_IPV6:
+ {
+ switch (optname)
+   {
+   case IPV6_TCLASS:
+ /* Unsupported */
+ ignore = true;
+ break;
+
+   default:
+ break;
+   }
+ }
+   default:
+ break;
}
 
-  /* Old applications still use the old WinSock1 IPPROTO_IP values. */
-  if (level == IPPROTO_IP 

vim-8.0.1376-1: Possible bug with ruby extensions

[Ameya Vikram Singh]

Hello,
Maintainers of the ViM/GViM text editor.

I am noticing that currently with the latest build of ViM
editor(vim-8.0.1376-1),
I am unable to use the command-t [1] plugin with this release.

When invoking the functionality with the key combination: `\` + `t`

I get the following error message on the ViM editor:

command-t.vim requires Vim to be compiled with Ruby support
For more information type:   :help command-t

When checking the vim feature from the bash terminal using:

vim --version

I do see in the output `+ruby/dyn`, which means that ruby support
should be enabled.

When checking for ruby compatibility with ViM using the following in
command mode:

:ruby puts RUBY_VERSION

One gets the following error message:

E448: Could not load library function rb_assoc_new
E266: Sorry, this command is disabled, the Ruby library could not be loaded.
Press ENTER or type command to continue

I will try to rebuild the from the sources (vim-8.0.1376-1-src) and
see if the error persists.

-- 
Thanks and Regards,
Ameya Vikram Singh

[1] https://github.com/wincent/command-t

--
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] Updated: mintty 2.8.4 {GOLDSTAR]

[Andrew Schulman]

> On 2018-02-05 21:45, Yaakov Selkowitz wrote:
> > On 2018-02-05 20:01, Andrew Schulman wrote:
> >>> I have uploaded mintty 2.8.4 with the following changes:
> >>
> >> I'll just take this opportunity to say thanks for maintaining this really
> >> central application in Cygwin. I use it every day to get my work done. 
> >> Andrew
> > 
> > Then let's do something about it. :-D
> 
> He should be severely castigated for his prescient behaviour of adding new
> features and fixing problems before we can report them. Should we pin an old
> guy's Gold Watch on him, give him five Golden Rings^WStars so long after Xmas,
> or do his mintty actions deserve the most extreme treatment, [Oh, no! 
> *NOT*...]
> the (Pink) Plush Hippo?

Awarded! http://cygwin.com/goldstars/#TW

BTW it's Known that 3 gold stars equals one plush hippo.

Andrew


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

setup 2.887 release candidate - please test

[Jon Turney]

A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.887.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.887.x86.exe(32 bit version)

Please test and report any problems here.

This is not the place for setup feature requests.

Changes compared to 2.884:

User visible changes:
- 'Current' is replaced by 'Best' (which is slightly different in ways 
it's difficult to summarize briefly) and 'Sync' (which exposes the 
--force-current (distupgrade) option through the UI).
- These are modified by a 'Test' checkbox, which allows test packages to 
be used.
- The "prereq" page showing dependencies which will be added is replaced 
by "problems" page showing problems found by the dependency solver, with 
default solutions.

- A "confirm" page is added showing all the changes which will be made.

Internal changes:
- Uses the libsolv dependency solver, rather than a home-made one.
- Add support for 'depends2: package (relation version) [...]', in a 
version section in setup.ini

- Add support for 'obsoletes:' in setup.ini, likewise
- Add support for 'replace-versions:' in a package section setup.ini, to 
indicate problematic versions.


Other:
- Query the user for action to take if a corrupt local file is found
- Validate package hash after download
- Any MessageBox shown during setup.ini parsing is now modal

A big 'thank you' to Ken Brown for all his work on this.

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

setup 2.887 release candidate - please test

[Jon Turney]

A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.887.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.887.x86.exe(32 bit version)

Please test and report any problems here.

This is not the place for setup feature requests.

Changes compared to 2.884:

User visible changes:
- 'Current' is replaced by 'Best' (which is slightly different in ways 
it's difficult to summarize briefly) and 'Sync' (which exposes the 
--force-current (distupgrade) option through the UI).
- These are modified by a 'Test' checkbox, which allows test packages to 
be used.
- The "prereq" page showing dependencies which will be added is replaced 
by "problems" page showing problems found by the dependency solver, with 
default solutions.

- A "confirm" page is added showing all the changes which will be made.

Internal changes:
- Uses the libsolv dependency solver, rather than a home-made one.
- Add support for 'depends2: package (relation version) [...]', in a 
version section in setup.ini

- Add support for 'obsoletes:' in setup.ini, likewise
- Add support for 'replace-versions:' in a package section setup.ini, to 
indicate problematic versions.


Other:
- Query the user for action to take if a corrupt local file is found
- Validate package hash after download
- Any MessageBox shown during setup.ini parsing is now modal

A big 'thank you' to Ken Brown for all his work on this.

Re: OpenBLAS patch for Cygwin

[Corinna Vinschen]

On Feb  6 15:15, Marco Atzeri wrote:
> On 06/02/2018 13:10, Erik Bray wrote:
> > Hello,
> > 
> > Users/maintainers of OpenBLAS on Cygwin may be interested in this
> > patch to improve support for fork():
> > https://github.com/xianyi/OpenBLAS/pull/1450
> > 
> > Assuming this looks good (feedback welcome) it might be nice to have
> > this patch included in the next release of the official OpenBLAS
> > package for Cygwin since its incompatibility with fork() has caused
> > problems in the past [1].
> > 
> > 
> > Thanks,
> > E
> > 
> > [1] https://trac.sagemath.org/ticket/22822
> > 
> 
> 
> Noted.
> Do you have a test case to show the failure with current build ?
> 
> Any reason to use OS_CYGWIN_NT and not __CYGWIN__ in the patch ?

Also, it should really use pthread functions and drop the notion that
Cygwin is a Windows target.  Assuming you're running fork from another
thread than the main thread, does it still work with native Windows
threads?


Corinna

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


signature.asc
Description: PGP signature

Re: RPC clnt_create() adress already in use

[Corinna Vinschen]

On Feb  6 11:29, PAULUS, Raimund, TI-ABN wrote:
> On Feb  5 15:06, Corinna Vinschen wrote:
> > On Feb  5 14:34, Corinna Vinschen wrote:
> > > On Feb  5 12:26, Corinna Vinschen wrote:
> > > > [...]
> > > > What potential solutions to this problem do we have?
> > > > 
> > > > - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
> > > >   sure bind fails.
> > > 
> > > Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the 
> > > second bind succeeding and the subsequent connect failing.  The 
> > > entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as 
> > > desired on the server side apparently
> > > 
> > > > - bindresvport could check every local address for being free prior
> > > >   to calling bind.  However, there's a potential race here.
> > > > 
> > > > - DisconnectEx?  Never tried this Winsock extension but it might be
> > > >   worth a shot.
> > 
> > I think I have a very simple solution for the scenario which calls 
> > bindresvport with port number.  Still looking for a solution for the 
> > second problem...
> 
> I've pushed a few patches and uploaded new developer snapshots to
> https://cygwin.com/snapshots.  Please give them a try.
> 
> with the snapshot of cygwin1.dll and using bindresvport() from Cygwin
> for libtirpc (instead of the original bindresvport() from libtirpc)
> all my testcases work without error.
> 
> Many thanks
> Raimund

Thanks for testing.  Please note that this should work most of the time,
but is still not 100% foolproof.  There's a systematic race between
checking existing connections and calling bind which can't be easily
worked around by Cygwin.  Still, should be better than before :}


Corinna

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


signature.asc
Description: PGP signature

Re: OpenBLAS patch for Cygwin

[Marco Atzeri]

On 06/02/2018 13:10, Erik Bray wrote:

Hello,

Users/maintainers of OpenBLAS on Cygwin may be interested in this
patch to improve support for fork():
https://github.com/xianyi/OpenBLAS/pull/1450

Assuming this looks good (feedback welcome) it might be nice to have
this patch included in the next release of the official OpenBLAS
package for Cygwin since its incompatibility with fork() has caused
problems in the past [1].


Thanks,
E

[1] https://trac.sagemath.org/ticket/22822




Noted.
Do you have a test case to show the failure with current build ?

Any reason to use OS_CYGWIN_NT and not __CYGWIN__ in the patch ?

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: cpan broken ???

[Pavel Fedin]

 Hello!

 Thank you for help; i just haven't got used to the new setup where you have to 
choose "Not installed" first.
 A small note: Looks like dependency list for these packages is missing. 
Nothing tells me that cpan wants PERL::YAML and JSON::XS;
and JSON::XS wants JSON.

Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia


> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
> Achim Gratz
> Sent: Monday, February 05, 2018 10:50 PM
> To: cygwin@cygwin.com
> Subject: Re: cpan broken ???
> 
> Pavel Fedin writes:
> >  Neither anything called "yaml" is listed in setup.exe
> 
> Well, I have
> 
> perl-CPAN-Meta-YAML
> perl-Test-YAML
> perl-YAML
> perl-YAML-LibYAML
> perl-YAML-Tiny
> 
> in setup.
> 
> 
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> SD adaptation for Waldorf microQ V2.22R2:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
> 
> --
> 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

OpenBLAS patch for Cygwin

[Erik Bray]

Hello,

Users/maintainers of OpenBLAS on Cygwin may be interested in this
patch to improve support for fork():
https://github.com/xianyi/OpenBLAS/pull/1450

Assuming this looks good (feedback welcome) it might be nice to have
this patch included in the next release of the official OpenBLAS
package for Cygwin since its incompatibility with fork() has caused
problems in the past [1].


Thanks,
E

[1] https://trac.sagemath.org/ticket/22822

--
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: RPC clnt_create() adress already in use

[PAULUS, Raimund, TI-ABN]

Hello Corinna,

with the snapshot of cygwin1.dll and using bindresvport() from Cygwin for 
libtirpc (instead of the original bindresvport() from libtirpc) all my 
testcases work without error.

Many thanks
Raimund



-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Corinna Vinschen
Gesendet: Montag, 5. Februar 2018 21:15
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

On Feb  5 15:06, Corinna Vinschen wrote:
> On Feb  5 14:34, Corinna Vinschen wrote:
> > On Feb  5 12:26, Corinna Vinschen wrote:
> > > To reiterate the problem we observe:
> > > 
> > > - socket()
> > > - setsockopt (SO_REUSEADDR)
> > > - bind() succeeds
> > > - connect() fails with EADDRINUSE while socket is still in 
> > > TIME_WAIT
> > > 
> > > using bindresvport in place of bind only marginally changes the 
> > > situation, in particular if the second parameter is set and 
> > > requests a port number != 0.  What happens in that case is that 
> > > bindresvport calls bind with this port number and checks if bind returns 
> > > EADDRINUSE.
> > > 
> > > Only then it tries to bind other port numbers in the reserved range.
> > > But we now know that bind will never return EADDINUSE if the 
> > > SO_REUSEADDR socket option has been set.
> > > 
> > > Even assuming the process calls bindresvport(sock, NULL) we may 
> > > end up returning a port number already in use if the process is 
> > > the only Cygwin process on the system.  The reason is that Cygwin 
> > > uses a round robin approach which relies on having a globally 
> > > shared value called last_used_bindresvport.  If the process is the 
> > > only Cygwin process on the system, this information is lost after 
> > > exiting the process, so the next process will start with the same 
> > > start port number and bind will again fail to notice the client with 
> > > EADDRINUSE.
> > > 
> > > What potential solutions to this problem do we have?
> > > 
> > > - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
> > >   sure bind fails.
> > 
> > Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the 
> > second bind succeeding and the subsequent connect failing.  The 
> > entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as 
> > desired on the server side apparently
> > 
> > > - bindresvport could check every local address for being free prior
> > >   to calling bind.  However, there's a potential race here.
> > > 
> > > - DisconnectEx?  Never tried this Winsock extension but it might be
> > >   worth a shot.
> 
> I think I have a very simple solution for the scenario which calls 
> bindresvport with port number.  Still looking for a solution for the 
> second problem...

I've pushed a few patches and uploaded new developer snapshots to 
https://cygwin.com/snapshots.  Please give them a try.


Thanks,
Corinna

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