[PATCH] Cygwin: define byteswap.h inlines as macros

[Yaakov Selkowitz]

The bswap_* "functions" are macros in glibc, so they may be tested for
by the preprocessor (e.g. #ifdef bswap_16).

Signed-off-by: Yaakov Selkowitz 
---
 winsup/cygwin/include/byteswap.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/include/byteswap.h b/winsup/cygwin/include/byteswap.h
index cd5a726..9f73c5a 100644
--- a/winsup/cygwin/include/byteswap.h
+++ b/winsup/cygwin/include/byteswap.h
@@ -16,23 +16,27 @@ extern "C" {
 #endif
 
 static __inline unsigned short
-bswap_16 (unsigned short __x)
+__bswap_16 (unsigned short __x)
 {
   return (__x >> 8) | (__x << 8);
 }
 
 static __inline unsigned int
-bswap_32 (unsigned int __x)
+__bswap_32 (unsigned int __x)
 {
-  return (bswap_16 (__x & 0x) << 16) | (bswap_16 (__x >> 16));
+  return (__bswap_16 (__x & 0x) << 16) | (__bswap_16 (__x >> 16));
 }
 
 static __inline unsigned long long
-bswap_64 (unsigned long long __x)
+__bswap_64 (unsigned long long __x)
 {
-  return (((unsigned long long) bswap_32 (__x & 0xull)) << 32) | 
(bswap_32 (__x >> 32));
+  return (((unsigned long long) __bswap_32 (__x & 0xull)) << 32) | 
(__bswap_32 (__x >> 32));
 }
 
+#define bswap_16(x) __bswap_16(x)
+#define bswap_32(x) __bswap_32(x)
+#define bswap_64(x) __bswap_64(x)
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.7.0

Re: Cygwin unable to resolve hostnames

[Jun-ya Kato]

> Is anybody here affected by this problem willing to give this a test?
> I can create another Cygwin 2.5.0 test release pretty soon...

I think it's useful workaround for cygwin user under VMware NAT.
I'd like to test it.






From: Corinna Vinschen 
Subject: Re: Cygwin unable to resolve hostnames
Date: Mon, 14 Mar 2016 10:54:59 +0100

> On Mar 14 09:34, Jun-ya Kato wrote:
>> It also depends on  query againt VMware's DNS proxy server.
>> 
>> For more analysis, see vmware community site,
>> https://communities.vmware.com/thread/518949?start=15=0
>> 
>> 
>> I think it is not cygwin's bug at all. but any workaround may be
>> implemented againt weak behavior of GetAddrInfoW() API.
> 
> As mentioned in the above posting, Cygwin always sets AI_ALL if
> ai_family is PF_UNSPEC and the hints don't specify AI_ADDRCONFIG.
> 
> Apparently Winsock's GetAddrInfoW chokes on AI_ALL in certain
> circumstances.  On GLibc, AI_ALL is ignored if AI_V4MAPPED is not given,
> but that's not as I observed it on Windows when I added this code
> (back in Vista times, but hey).
> 
> There's an easy workaround possible:  If GetAddrInfoW returns the
> error code WSANO_RECOVERY (per the above posting), we can retry
> without the AI_ALL flag.
> 
> Is anybody here affected by this problem willing to give this a test?
> I can create another Cygwin 2.5.0 test release pretty soon...
> 
> 
> Thanks,
> 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

ctrl-c doesn't reliably kill ping

[Frank Farance]

I have been having this problem with "ping".  If I "ping" a location that 
doesn't exist, then "ping" just hangs and cannot be killed via "kill -KILL [pid]".


A little digression, so you understand the background ... The workstation I am 
doing this from is connected to a Verizon router to their FIOS network.  Now the 
reason I mention this is that the router's DNS (via DHCP to my workstation) is 
192.168.1.1, which I presume is forwarded from the router upstream to Verizon's 
DNS caches.  So if I type the URL http://something.that.doesnt.exist in my 
browser, rather than getting a Hostname Not Found error (at the name resolution 
level), it actually loads up a page saying "something.that.doesnt.exist" isn't 
found and then I have a Yahoo set of search results on things matching the 
broken hostname.


So all of this is normal ISP stuff: they actually resolve unknown addresses to 
their own website (which is 90.242.140.21).


Ok, ending the digression 

Back to the problem, so when I type

$ ping some.unknown.host

according to "ping", the hostname resolves to 90.242.140.21 (as per the 
explanation above), but I cannot kill "ping".  I tried "ping" with a limited 
packet size and count so, in theory, "ping" would die on its own after 10 
packets, such as:


$ ping some.unknown.host 50 10

but it still hangs rather than timing out.  If I ping to some actual IP address 
that is unresponsive (route-able to the last subnet, but dies on the floor at 
the end), then I can kill via ctrl-c.  My only solution to the hanging "ping" is 
to kill the terminal window.


Any suggestions on:

- Why "ping" behaves this way?
- How to avoid this problem?

Thanks, in advance.

-FF

--
__
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: ctrl-c doesn't reliably kill applications

[Kaz Kylheku]

On 14.03.2016 10:18, Björn Stabel wrote:
 

My eyes blinked there for a second! Nope, not the Xpilot
co-author, Norwegian Bjørn Stabell.

:)


--
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: [PATCH] Regenerate newlib/configure

[Peter Foley]

On Mon, Mar 14, 2016 at 12:23 PM, Peter Foley  wrote:
> Fix undefined libtool macros _LT_DECL_SED and _LT_PROG_ECHO_BACKSLASH
>
> newlib/ChangeLog
> * configure: Regenerate.
>
> ---
>  newlib/configure | 9339 
> +-
>  1 file changed, 9306 insertions(+), 33 deletions(-)


Whoops,

Just realized that this should have been sent to the newlib list.
I'll re-submit this there.

Thanks,

Peter Foley

Re: ldd differences

[Roger Wells]

On 03/14/2016 03:50 PM, Roger Wells wrote:
> On 03/14/2016 03:09 PM, Achim Gratz wrote:
>> Roger Wells writes:
 Try cygcheck rather than ldd.

>>> Thanks for responding.
>>>
>>> Here's what happens:
>>>
>>> $ cygcheck ./z12.exe
>>> C:\cygwin64\home\roger\src\z12\z12.exe
>>>
>>> or
>>>
>>> $ cygcheck --verbose ./z12.exe
>>> C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)
>>
>> Then it doesn't seem to be a Cygwin binary.  Is that the product of some
>> cross-compilation, perhaps?
>>
> 
> It was built with MinGW GCC 4.9.3 (32 bit)
> However, recall that the older 32 bit cygwin ldd had no problem with it.
> We have been using MinGW in a Cygwin environment for over two decades
> with out surprises.  I wonder if the fact that the executable is 32-bit
> is the culprit and the 64 bit Cygwin tools are expecting 64 bit items to
> work on?  I expect that ldd etc are attempting to do what the OS does
> when it loads the executable wrt identifying what resources (i.e. dll's)
> are required.  It shouldn't matter what tool built it and both 32 bit
> and 64 bit items are going to be around for a while and both need to be
> handled correctly.  I'll probably install 32 bit Cygwin and test the
> hypothesis.  I'll let you know.
> 
> 
> cheers,
> roger
> 
Here is what happens with cygcheck from a new 32 bit Cygwin install:

$ c:/cygwin/bin/cygcheck ./z12.exe
C:\cygwin64\home\roger\src\z12\z12.exe
  C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
  C:\WINDOWS\system32\api-ms-win-eventing-provider-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-handle-l1-1-0.dll
C:\WINDOWS\system32\api-ms-win-core-synch-l1-2-0.dll
C:\WINDOWS\system32\api-ms-win-core-timezone-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-string-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-util-l1-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-profile-l1-1-0.dll
C:\WINDOWS\system32\api-ms-win-core-xstate-l2-1-0.dll
C:\Program Files\TortoiseSVN\bin\api-ms-win-core-console-l1-1-0.dll
  C:\WINDOWS\system32\msvcrt.dll
  C:\cygwin64\home\roger\lib\libnmea0183.dll
C:\MinGW\bin\libgcc_s_dw2-1.dll
C:\MinGW\bin\libstdc++-6.dll
  C:\cygwin64\home\roger\lib\libsensors.dll
C:\cygwin64\home\roger\lib\libutility.dll
  C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\SECHOST.dll
  C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\SspiCli.dll
  C:\WINDOWS\system32\CRYPTBASE.dll
C:\WINDOWS\system32\bcryptPrimitives.dll
  C:\WINDOWS\system32\USER32.dll
C:\WINDOWS\system32\GDI32.dll
  C:\WINDOWS\system32\WINMM.DLL
C:\WINDOWS\system32\WINMMBASE.dll
  C:\WINDOWS\system32\WSOCK32.DLL
C:\WINDOWS\system32\WS2_32.dll
  C:\cygwin64\home\roger\lib\libfilters.dll

Much more useful.

cheers again,
roger

>>
>> Regards,
>> Achim.
>>
> 
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
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: ldd differences

[Roger Wells]

On 03/14/2016 03:09 PM, Achim Gratz wrote:
> Roger Wells writes:
>>> Try cygcheck rather than ldd.
>>>
>> Thanks for responding.
>>
>> Here's what happens:
>>
>> $ cygcheck ./z12.exe
>> C:\cygwin64\home\roger\src\z12\z12.exe
>>
>> or
>>
>> $ cygcheck --verbose ./z12.exe
>> C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)
> 
> Then it doesn't seem to be a Cygwin binary.  Is that the product of some
> cross-compilation, perhaps?
> 

It was built with MinGW GCC 4.9.3 (32 bit)
However, recall that the older 32 bit cygwin ldd had no problem with it.
We have been using MinGW in a Cygwin environment for over two decades
with out surprises.  I wonder if the fact that the executable is 32-bit
is the culprit and the 64 bit Cygwin tools are expecting 64 bit items to
work on?  I expect that ldd etc are attempting to do what the OS does
when it loads the executable wrt identifying what resources (i.e. dll's)
are required.  It shouldn't matter what tool built it and both 32 bit
and 64 bit items are going to be around for a while and both need to be
handled correctly.  I'll probably install 32 bit Cygwin and test the
hypothesis.  I'll let you know.


cheers,
roger

> 
> Regards,
> Achim.
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
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] Re-Release: _autorebase-001003-2

[Achim Gratz]

The _autorebase package has been re-relaesd to fix a packaging error
that resulted in too restricted permissions for the installed script
files.  No other changes have been made.

-- 
  *** 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@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: ldd differences

[Achim Gratz]

Roger Wells writes:
>> Try cygcheck rather than ldd.
>> 
> Thanks for responding.
>
> Here's what happens:
>
> $ cygcheck ./z12.exe
> C:\cygwin64\home\roger\src\z12\z12.exe
>
> or
>
> $ cygcheck --verbose ./z12.exe
> C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)

Then it doesn't seem to be a Cygwin binary.  Is that the product of some
cross-compilation, perhaps?


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

SD adaptation for Waldorf rackAttack V1.04R1:
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

RE: font faq

[Rockefeller, Harry]

>-Original Message-
>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
>Yaakov Selkowitz
>Sent: Monday, March 14, 2016 10:37 AM
>To: cygwin@cygwin.com
>Subject: Re: font faq
>
>On 2016-03-14 09:54, Rockefeller, Harry wrote:
>> I have had warnings and errors about fonts ever since  -  something changed.
>> I'm looking at the index of Cygwin FAQ and there is not a single question 
>> matching 'font'.
>> Where do I need to go to match up my font issue (warning or error) on
>> a particular font with the font package I need to install?
>
>Every message on this list, including yours, points to:
>
> Problem reports:   http://cygwin.com/problems.html

I exited and restarted Cygwin and was unable to reproduce my last font warning 
message.
I wrote this up trying to make it more a "documentation" issue.  I guess I 
failed.
Thanks for your volunteer efforts to make Cygwin such a great product.

--
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: ldd differences

[Roger Wells]

On 03/14/2016 01:38 PM, Achim Gratz wrote:
> Roger Wells writes:
>> running ldd on a newly built executable gives:
> […]
>> What I really need is a reliable way to get a recursive listing of the
>> complete path to all dependencies.
>> I tried using Dependency Walker (both 32 & 64 bit) but it does not seem
>> to run on W10.
> 
> Try cygcheck rather than ldd.
> 
Thanks for responding.

Here's what happens:

$ cygcheck ./z12.exe
C:\cygwin64\home\roger\src\z12\z12.exe

or

$ cygcheck --verbose ./z12.exe
C:\cygwin64\home\roger\src\z12\z12.exe (not x86_64 dll)


> 
> Regards,
> Achim.
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
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: ldd differences

[Achim Gratz]

Roger Wells writes:
> running ldd on a newly built executable gives:
[…]
> What I really need is a reliable way to get a recursive listing of the
> complete path to all dependencies.
> I tried using Dependency Walker (both 32 & 64 bit) but it does not seem
> to run on W10.

Try cygcheck rather than ldd.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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] xterm 324-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* xterm-324-1

The xterm program is a terminal emulator for the X Window System. It 
provides DEC VT102 and Tektronix 4014 compatible terminals for programs 
that can't use the window system directly. This version implements 
ISO/ANSI colors using the 'new' color model (i.e., background color 
erase). It also implements most of the control sequences for VT220.

This is an update to the latest upstream release.

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

xterm 324-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* xterm-324-1

The xterm program is a terminal emulator for the X Window System. It 
provides DEC VT102 and Tektronix 4014 compatible terminals for programs 
that can't use the window system directly. This version implements 
ISO/ANSI colors using the 'new' color model (i.e., background color 
erase). It also implements most of the control sequences for VT220.

This is an update to the latest upstream release.

--
Yaakov

[ANNOUNCEMENT] vim 7.4.1558-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* vim-7.4.1558-1
* vim-common-7.4.1558-1
* vim-minimal-7.4.1558-1
* gvim-7.4.1558-1
* xxd-7.4.1558-1
* vim-doc-7.4.1558-1

Vim (Vi IMproved) is an almost compatible version of the UNIX editor vi. 
Almost every possible command can be performed using only ASCII 
characters. Many new features have been added: multilevel undo, command 
line history, file name completion, block operations, and editing of 
binary data.

This is an update to last night's upstream patchset.

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

vim 7.4.1558-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* vim-7.4.1558-1
* vim-common-7.4.1558-1
* vim-minimal-7.4.1558-1
* gvim-7.4.1558-1
* xxd-7.4.1558-1
* vim-doc-7.4.1558-1

Vim (Vi IMproved) is an almost compatible version of the UNIX editor vi. 
Almost every possible command can be performed using only ASCII 
characters. Many new features have been added: multilevel undo, command 
line history, file name completion, block operations, and editing of 
binary data.

This is an update to last night's upstream patchset.

--
Yaakov

ctrl-c doesn't reliably kill applications

[Björn Stabel]

The ctrl-c shortcut doesn't reliably kill applications (anymore?).
It has been that way for at least a year now.



One example is the ruby "rerun" tool (at least when used with a sinatra
app).
The problem can be reproduced using these steps:

 1. Default cygwin install
 2. Install rubygems package
 3. gem install rerun sinatra
 4. Make sure the rerun tool is in PATH (or specify the path to it
explicitly). I think rubygems installs executables from gems to
~/bin by default
 5. rerun "ruby -e 'require(\"sinatra\")'"
 6. ctrl-c
 7. tasklist /fi "IMAGENAME eq ruby.exe"
  * Expected: No process
  * Actual: process is still running

You might have to repeat steps 5 to 7 a few times for the issue to occur.
Another problem is that Q sometimes doesn't exit rerun but only the app
running inside, but that might be a problem with rerun itself or with
the shutdown detection they use.



Another example is Vagrant.
Although that is not a cygwin application, I usually recommend coworkers
to use it with cygwin, because it benefits from mintty's better console.
The problem there occurs when you invoke a long-running vagrant command
(vagrant provision, for instance) and then cancel it with ctrl-c.
If you do that, you're back at the bash prompt, but the provisioning run
still goes on and spams the console, making it unusable.



Under Kubuntu Linux 14.04/kde/konsole/bash, neither of these problems exist.
What the two examples seem to have in common is that they're both one
application invoking another:

  * rerun invokes sh -c "$1" (I think)
  * vagrant provision invokes (its bundled?) ssh

I think this is a bug and should be fixed. Is the bug with Cygwin or
should I report it elsewhere?

- Björn Stabel aka. TomyLobo

--
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_getaddrinfo: workaround Winsock getaddrinfo issue with broken DNS

[Corinna Vinschen]

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

commit 7176a85cd48d37bc068312ffa79f254305cf4511
Author: Corinna Vinschen 
Date:   Mon Mar 14 17:57:22 2016 +0100

cygwin_getaddrinfo: workaround Winsock getaddrinfo issue with broken DNS

Add experimental code to workaround the issue described in the thread
starting at

  https://cygwin.com/ml/cygwin/2015-07/msg00350.html

There's a hint in https://communities.vmware.com/message/2577858#2577858
that this problem is related to using the AI_ALL flag.

This patch checks if GetAddrInfoW returned with WSANO_RECOVERY and if
the AI_ALL flag was set, it retries GetAddrInfo without the AI_ALL flag.

* net.cc (cygwin_getaddrinfo): Add experimental code to retry
GetAddrInfoW without AI_ALL flag if it returned with WSANO_RECOVERY.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/net.cc | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index f046a3b..31bc11d 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -3595,7 +3595,16 @@ cygwin_getaddrinfo (const char *hostname, const char 
*servname,
}
   /* Disable automatic IDN conversion on W8 and later. */
   whints.ai_flags |= AI_DISABLE_IDN_ENCODING;
-  ret = w32_to_gai_err (GetAddrInfoW (whost, wserv, , ));
+  ret = GetAddrInfoW (whost, wserv, , );
+  /* Try to workaround an apparent shortcoming in Winsock's getaddrinfo
+implementation.  See this link for details:
+https://communities.vmware.com/message/2577858#2577858 */
+  if (ret == WSANO_RECOVERY && (whints.ai_flags & AI_ALL))
+   {
+ whints.ai_flags &= ~AI_ALL;
+ ret = GetAddrInfoW (whost, wserv, , );
+   }
+  ret = w32_to_gai_err (ret);
   /* Always copy over to self-allocated memory. */
   if (!ret)
{

Re: font faq

[Yaakov Selkowitz]

On 2016-03-14 09:54, Rockefeller, Harry wrote:

I have had warnings and errors about fonts ever since  -  something changed.
I'm looking at the index of Cygwin FAQ and there is not a single question 
matching 'font'.
Where do I need to go to match up my font issue (warning or error) on a 
particular font with the
font package I need to install?


Every message on this list, including yours, points to:


Problem reports:   http://cygwin.com/problems.html


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

ldd differences

[Roger Wells]

On a 32 bit Cygwin installation on a Windows 7 host that is a few years old:

$ uname -a
CYGWIN_NT-6.1-WOW64 DET000-DAC1 1.7.17(0.262/5/3) 2012-10-19 14:39 i686
Cygwin

running ldd on a newly built executable gives:

$ ldd z12.exe
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77df)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x75b4)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x766c)
msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x75c5)
libnmea0183.dll => /cygdrive/d/iss60/dll/libnmea0183.dll (0x614c)
libsensors.dll => /cygdrive/d/iss60/dll/libsensors.dll (0x68cc)
libutility.dll => /cygdrive/d/iss60/dll/libutility.dll (0x70cc)
ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x75a7)
sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7615)
RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x762d)
SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x754b)
CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x754a)
USER32.dll => /cygdrive/c/Windows/syswow64/USER32.dll (0x7584)
GDI32.dll => /cygdrive/c/Windows/syswow64/GDI32.dll (0x7572)
LPK.dll => /cygdrive/c/Windows/syswow64/LPK.dll (0x766b)
USP10.dll => /cygdrive/c/Windows/syswow64/USP10.dll (0x763c)
WINMM.DLL => /cygdrive/c/Windows/system32/WINMM.DLL (0x71ee)
WSOCK32.DLL => /cygdrive/c/Windows/system32/WSOCK32.DLL (0x72b1)
WS2_32.dll => /cygdrive/c/Windows/syswow64/WS2_32.dll (0x75f2)
NSI.dll => /cygdrive/c/Windows/syswow64/NSI.dll (0x7571)
libfilters.dll => /cygdrive/d/iss60/dll/libfilters.dll (0x6dc4)
IMM32.DLL => /cygdrive/c/Windows/system32/IMM32.DLL (0x756b)
MSCTF.dll => /cygdrive/c/Windows/syswow64/MSCTF.dll (0x75ff)

An expected list containing dependencies on Windows and our own DLL's.

On a quite new 64 bit Cygwin running on a Windows 10 host:

$ uname -a
CYGWIN_NT-10.0 rwells-x220 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin

Running ldd on the same executable file gives:

$ ldd z12.exe
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe2bfd)
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x774b)
wow64.dll => /cygdrive/c/WINDOWS/system32/wow64.dll (0x7229)
wow64win.dll => /cygdrive/c/WINDOWS/system32/wow64win.dll (0x722e)
??? => ??? (0xc)
KERNEL32.DLL => /cygdrive/c/WINDOWS/SYSTEM32/KERNEL32.DLL (0x76a6)
??? => ??? (0xc)
??? => ??? (0x65)
wow64cpu.dll => /cygdrive/c/WINDOWS/system32/wow64cpu.dll (0x7228)
KERNEL32.DLL => /cygdrive/c/WINDOWS/SYSTEM32/KERNEL32.DLL (0x76a6)
KERNELBASE.dll => /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
(0x7587)
msvcrt.dll => /cygdrive/c/WINDOWS/SYSTEM32/msvcrt.dll (0x76e5)


And the executable, z12.exe, does run correctly on both systems.

What I really need is a reliable way to get a recursive listing of the
complete path to all dependencies.
I tried using Dependency Walker (both 32 & 64 bit) but it does not seem
to run on W10.

TIA


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com



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

font faq

[Rockefeller, Harry]

$ uname -a
CYGWIN_NT-6.1-WOW HARRYR-PC 2.4.1(0.293/5/3) 2016-01-24 11:24 i686 Cygwin

I have had warnings and errors about fonts ever since  -  something changed.
I'm looking at the index of Cygwin FAQ and there is not a single question 
matching 'font'.
Where do I need to go to match up my font issue (warning or error) on a 
particular font with the
font package I need to install?


--
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: [PATCH] Re: Cygwin select() issues and improvements

[Corinna Vinschen]

Hi John,

On Mar 13 17:37, john hood wrote:
> On 3/4/16 3:58 AM, Corinna Vinschen wrote:
> > John,
> > 
> > 
> > Ping?  I'd be interested to get your patches into Cygwin.  select
> > really needs some kicking :)
> 
> Sorry to be so slow responding.  Here's a rebased, squashed,
> changelog-ified patch,

Thank you.  Uhm... I just don't understand why you squashed them into a
single big patch.  Multiple independent smaller patches are better to
handle, especially when looking for potential bugs later.

Would you mind terribly to split them again?

> and I've sent an assignment in to Red Hat.

Cool, thanks!  This might take a few days.

> Aside:  Why maintain Git comments in ChangeLog format?  That made sense
> up into the CVS era, but now version control systems and viewers provide
> most of the details that a ChangeLog needed to list, and newlib/Cygwin
> has stopped maintaining ChangeLogs.

It's probably the "get off my lawn" mentality of old, die-hard CVS users.
Both, Jeff and I, the maintainers of newlib and Cygwin are such specimen.

I'm in the process of reconsidering it for Cygwin-related logs.  I'm still
mostly sticking to these ChangeLog entries, but I'm moving over to adding
textual descriptions to the git log.  See my latest commits for examples.


Corinna

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


signature.asc
Description: PGP signature

Re: Cygwin unable to resolve hostnames

[Corinna Vinschen]

On Mar 14 09:34, Jun-ya Kato wrote:
> It also depends on  query againt VMware's DNS proxy server.
> 
> For more analysis, see vmware community site,
> https://communities.vmware.com/thread/518949?start=15=0
> 
> 
> I think it is not cygwin's bug at all. but any workaround may be
> implemented againt weak behavior of GetAddrInfoW() API.

As mentioned in the above posting, Cygwin always sets AI_ALL if
ai_family is PF_UNSPEC and the hints don't specify AI_ADDRCONFIG.

Apparently Winsock's GetAddrInfoW chokes on AI_ALL in certain
circumstances.  On GLibc, AI_ALL is ignored if AI_V4MAPPED is not given,
but that's not as I observed it on Windows when I added this code
(back in Vista times, but hey).

There's an easy workaround possible:  If GetAddrInfoW returns the
error code WSANO_RECOVERY (per the above posting), we can retry
without the AI_ALL flag.

Is anybody here affected by this problem willing to give this a test?
I can create another Cygwin 2.5.0 test release pretty soon...


Thanks,
Corinna

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


signature.asc
Description: PGP signature