* Version 1.8.1 does not compile on Cygwin 1.7.14
@ 2013-01-06 2:04 Stephen & Linda Smith
2013-01-06 3:37 ` Jason Pyeron
2013-01-06 6:20 ` Stephen & Linda Smith
0 siblings, 2 replies; 45+ messages in thread
From: Stephen & Linda Smith @ 2013-01-06 2:04 UTC (permalink / raw)
To: git; +Cc: mlevedahl, gitster
Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message states that
the macro was being renamed for clarity. The patch also changes a define.
This change causes the code to not compile on cygwin 1.7.14.
I narrowed the problem to this patch by bisecting commits between v1.8.0 and
1.8.1
Here is the error sequence:
CC compat/cygwin.o
In file included from compat/../git-compat-util.h:90,
from compat/cygwin.c:9:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2:
warning: #warning "fd_set and associated macros have been defined in sys/types.
This may cause runtime problems with W32 sockets"
In file included from /usr/include/sys/socket.h:16,
from compat/../git-compat-util.h:131,
from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr'
/usr/include/cygwin/socket.h:41: error: redefinition of `struct
sockaddr_storage'
In file included from /usr/include/sys/socket.h:16,
from compat/../git-compat-util.h:131,
from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:59: error: redefinition of `struct linger'
In file included from compat/../git-compat-util.h:131,
from compat/cygwin.c:9:
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536:
error: previous declaration of 'accept' was here
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536:
error: previous declaration of 'accept' was here
/usr/include/sys/socket.h:32: error: conflicting types for 'bind'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537:
error: previous declaration of 'bind' was here
/usr/include/sys/socket.h:32: error: conflicting types for 'bind'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537:
error: previous declaration of 'bind' was here
/usr/include/sys/socket.h:33: error: conflicting types for 'connect'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539:
error: previous declaration of 'connect' was here
/usr/include/sys/socket.h:33: error: conflicting types for 'connect'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539:
error: previous declaration of 'connect' was here
/usr/include/sys/socket.h:34: error: conflicting types for 'getpeername'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541:
error: previous declaration of 'getpeername' was here
/usr/include/sys/socket.h:34: error: conflicting types for 'getpeername'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541:
error: previous declaration of 'getpeername' was here
/usr/include/sys/socket.h:35: error: conflicting types for 'getsockname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542:
error: previous declaration of 'getsockname' was here
/usr/include/sys/socket.h:35: error: conflicting types for 'getsockname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542:
error: previous declaration of 'getsockname' was here
/usr/include/sys/socket.h:36: error: conflicting types for 'listen'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546:
error: previous declaration of 'listen' was here
/usr/include/sys/socket.h:36: error: conflicting types for 'listen'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546:
error: previous declaration of 'listen' was here
/usr/include/sys/socket.h:37: error: conflicting types for 'recv'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547:
error: previous declaration of 'recv' was here
/usr/include/sys/socket.h:37: error: conflicting types for 'recv'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547:
error: previous declaration of 'recv' was here
/usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548:
error: previous declaration of 'recvfrom' was here
/usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548:
error: previous declaration of 'recvfrom' was here
/usr/include/sys/socket.h:41: error: conflicting types for 'send'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549:
error: previous declaration of 'send' was here
/usr/include/sys/socket.h:41: error: conflicting types for 'send'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549:
error: previous declaration of 'send' was here
/usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:550:
error: previous declaration of 'sendto' was here
/usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:550:
error: previous declaration of 'sendto' was here
/usr/include/sys/socket.h:46: error: conflicting types for 'setsockopt'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:551:
error: previous declaration of 'setsockopt' was here
/usr/include/sys/socket.h:46: error: conflicting types for 'setsockopt'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:551:
error: previous declaration of 'setsockopt' was here
/usr/include/sys/socket.h:48: error: conflicting types for 'getsockopt'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:543:
error: previous declaration of 'getsockopt' was here
/usr/include/sys/socket.h:48: error: conflicting types for 'getsockopt'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:543:
error: previous declaration of 'getsockopt' was here
/usr/include/sys/socket.h:49: error: conflicting types for 'shutdown'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:552:
error: previous declaration of 'shutdown' was here
/usr/include/sys/socket.h:49: error: conflicting types for 'shutdown'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:552:
error: previous declaration of 'shutdown' was here
/usr/include/sys/socket.h:50: error: conflicting types for 'socket'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:553:
error: previous declaration of 'socket' was here
/usr/include/sys/socket.h:50: error: conflicting types for 'socket'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:553:
error: previous declaration of 'socket' was here
/usr/include/sys/socket.h:53: error: conflicting types for 'getservbyname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:557:
error: previous declaration of 'getservbyname' was here
/usr/include/sys/socket.h:53: error: conflicting types for 'getservbyname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:557:
error: previous declaration of 'getservbyname' was here
In file included from compat/../git-compat-util.h:135,
from compat/cygwin.c:9:
/usr/include/sys/select.h:31: error: conflicting types for 'select'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:632:
error: previous declaration of 'select' was here
/usr/include/sys/select.h:31: error: conflicting types for 'select'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:632:
error: previous declaration of 'select' was here
In file included from /usr/include/netinet/in.h:14,
from compat/../git-compat-util.h:137,
from compat/cygwin.c:9:
/usr/include/cygwin/in.h:30: error: parse error before numeric constant
/usr/include/cygwin/in.h:35: error: parse error before numeric constant
/usr/include/cygwin/in.h:37: error: parse error before numeric constant
/usr/include/cygwin/in.h:76: error: parse error before numeric constant
/usr/include/cygwin/in.h:115: error: redefinition of `struct in_addr'
/usr/include/cygwin/in.h:116: error: parse error before '.' token
/usr/include/cygwin/in.h:184: error: redefinition of `struct sockaddr_in'
In file included from /usr/include/cygwin/in.h:250,
from /usr/include/netinet/in.h:14,
from compat/../git-compat-util.h:137,
from compat/cygwin.c:9:
/usr/include/asm/byteorder.h:26: error: conflicting types for 'ntohl'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:629:
error: previous declaration of 'ntohl' was here
/usr/include/asm/byteorder.h:26: error: conflicting types for 'ntohl'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:629:
error: previous declaration of 'ntohl' was here
/usr/include/asm/byteorder.h:27: error: conflicting types for 'ntohs'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:631:
error: previous declaration of 'ntohs' was here
/usr/include/asm/byteorder.h:27: error: conflicting types for 'ntohs'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:631:
error: previous declaration of 'ntohs' was here
/usr/include/asm/byteorder.h:28: error: conflicting types for 'htonl'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:628:
error: previous declaration of 'htonl' was here
/usr/include/asm/byteorder.h:28: error: conflicting types for 'htonl'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:628:
error: previous declaration of 'htonl' was here
/usr/include/asm/byteorder.h:29: error: conflicting types for 'htons'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:630:
error: previous declaration of 'htons' was here
/usr/include/asm/byteorder.h:29: error: conflicting types for 'htons'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:630:
error: previous declaration of 'htons' was here
In file included from compat/../git-compat-util.h:139,
from compat/cygwin.c:9:
/usr/include/arpa/inet.h:22: error: conflicting types for 'inet_addr'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:544:
error: previous declaration of 'inet_addr' was here
/usr/include/arpa/inet.h:22: error: conflicting types for 'inet_addr'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:544:
error: previous declaration of 'inet_addr' was here
/usr/include/arpa/inet.h:28: error: conflicting types for 'inet_ntoa'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:545:
error: previous declaration of 'inet_ntoa' was here
/usr/include/arpa/inet.h:28: error: conflicting types for 'inet_ntoa'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:545:
error: previous declaration of 'inet_ntoa' was here
In file included from compat/../git-compat-util.h:140,
from compat/cygwin.c:9:
/usr/include/netdb.h:79: error: redefinition of `struct hostent'
/usr/include/netdb.h:93: error: redefinition of `struct netent'
/usr/include/netdb.h:100: error: redefinition of `struct servent'
/usr/include/netdb.h:108: error: redefinition of `struct protoent'
/usr/include/netdb.h:139: error: conflicting types for 'WSAGetLastError'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:594:
error: previous declaration of 'WSAGetLastError' was here
/usr/include/netdb.h:139: error: conflicting types for 'WSAGetLastError'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:594:
error: previous declaration of 'WSAGetLastError' was here
/usr/include/netdb.h:192: error: conflicting types for 'gethostbyaddr'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:554:
error: previous declaration of 'gethostbyaddr' was here
/usr/include/netdb.h:192: error: conflicting types for 'gethostbyaddr'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:554:
error: previous declaration of 'gethostbyaddr' was here
/usr/include/netdb.h:193: error: conflicting types for 'gethostbyname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:555:
error: previous declaration of 'gethostbyname' was here
/usr/include/netdb.h:193: error: conflicting types for 'gethostbyname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:555:
error: previous declaration of 'gethostbyname' was here
/usr/include/netdb.h:199: error: conflicting types for 'getprotobyname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:559:
error: previous declaration of 'getprotobyname' was here
/usr/include/netdb.h:199: error: conflicting types for 'getprotobyname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:559:
error: previous declaration of 'getprotobyname' was here
/usr/include/netdb.h:200: error: conflicting types for 'getprotobynumber'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:558:
error: previous declaration of 'getprotobynumber' was here
/usr/include/netdb.h:200: error: conflicting types for 'getprotobynumber'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:558:
error: previous declaration of 'getprotobynumber' was here
/usr/include/netdb.h:203: error: conflicting types for 'getservbyport'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:556:
error: previous declaration of 'getservbyport' was here
/usr/include/netdb.h:203: error: conflicting types for 'getservbyport'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:556:
error: previous declaration of 'getservbyport' was here
Makefile:2384: recipe for target `compat/cygwin.o' failed
make: *** [compat/cygwin.o] Error 1
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 2:04 Version 1.8.1 does not compile on Cygwin 1.7.14 Stephen & Linda Smith
@ 2013-01-06 3:37 ` Jason Pyeron
2013-01-06 4:22 ` Jason Pyeron
2013-01-06 6:20 ` Stephen & Linda Smith
1 sibling, 1 reply; 45+ messages in thread
From: Jason Pyeron @ 2013-01-06 3:37 UTC (permalink / raw)
To: git
> Stephen & Linda Smith
> Sent: Saturday, January 05, 2013 21:05
>
> Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message
> states that the macro was being renamed for clarity. The
> patch also changes a define.
Was it the commit before 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles
or was it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I am doing a
cygwin update presently to look at it.
>
> This change causes the code to not compile on cygwin 1.7.14.
>
> I narrowed the problem to this patch by bisecting commits
> between v1.8.0 and
> 1.8.1
>
> Here is the error sequence:
>
> CC compat/cygwin.o
> In file included from compat/../git-compat-util.h:90,
> from compat/cygwin.c:9:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:103:2:
> warning: #warning "fd_set and associated macros have been
> defined in sys/types.
> This may cause runtime problems with W32 sockets"
> In file included from /usr/include/sys/socket.h:16,
> from compat/../git-compat-util.h:131,
> from compat/cygwin.c:9:
> /usr/include/cygwin/socket.h:29: error: redefinition of
> `struct sockaddr'
> /usr/include/cygwin/socket.h:41: error: redefinition of
> `struct sockaddr_storage'
> In file included from /usr/include/sys/socket.h:16,
> from compat/../git-compat-util.h:131,
> from compat/cygwin.c:9:
> /usr/include/cygwin/socket.h:59: error: redefinition of
> `struct linger'
> In file included from compat/../git-compat-util.h:131,
> from compat/cygwin.c:9:
> /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:536:
> error: previous declaration of 'accept' was here
> /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:536:
> error: previous declaration of 'accept' was here
> /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:537:
> error: previous declaration of 'bind' was here
> /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:537:
> error: previous declaration of 'bind' was here
> /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:539:
> error: previous declaration of 'connect' was here
> /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:539:
> error: previous declaration of 'connect' was here
> /usr/include/sys/socket.h:34: error: conflicting types for
> 'getpeername'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:541:
> error: previous declaration of 'getpeername' was here
> /usr/include/sys/socket.h:34: error: conflicting types for
> 'getpeername'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:541:
> error: previous declaration of 'getpeername' was here
> /usr/include/sys/socket.h:35: error: conflicting types for
> 'getsockname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:542:
> error: previous declaration of 'getsockname' was here
> /usr/include/sys/socket.h:35: error: conflicting types for
> 'getsockname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:542:
> error: previous declaration of 'getsockname' was here
> /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:546:
> error: previous declaration of 'listen' was here
> /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:546:
> error: previous declaration of 'listen' was here
> /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:547:
> error: previous declaration of 'recv' was here
> /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:547:
> error: previous declaration of 'recv' was here
> /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:548:
> error: previous declaration of 'recvfrom' was here
> /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:548:
> error: previous declaration of 'recvfrom' was here
> /usr/include/sys/socket.h:41: error: conflicting types for 'send'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:549:
> error: previous declaration of 'send' was here
> /usr/include/sys/socket.h:41: error: conflicting types for 'send'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:549:
> error: previous declaration of 'send' was here
> /usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:550:
> error: previous declaration of 'sendto' was here
> /usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:550:
> error: previous declaration of 'sendto' was here
> /usr/include/sys/socket.h:46: error: conflicting types for
> 'setsockopt'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:551:
> error: previous declaration of 'setsockopt' was here
> /usr/include/sys/socket.h:46: error: conflicting types for
> 'setsockopt'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:551:
> error: previous declaration of 'setsockopt' was here
> /usr/include/sys/socket.h:48: error: conflicting types for
> 'getsockopt'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:543:
> error: previous declaration of 'getsockopt' was here
> /usr/include/sys/socket.h:48: error: conflicting types for
> 'getsockopt'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:543:
> error: previous declaration of 'getsockopt' was here
> /usr/include/sys/socket.h:49: error: conflicting types for 'shutdown'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:552:
> error: previous declaration of 'shutdown' was here
> /usr/include/sys/socket.h:49: error: conflicting types for 'shutdown'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:552:
> error: previous declaration of 'shutdown' was here
> /usr/include/sys/socket.h:50: error: conflicting types for 'socket'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:553:
> error: previous declaration of 'socket' was here
> /usr/include/sys/socket.h:50: error: conflicting types for 'socket'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:553:
> error: previous declaration of 'socket' was here
> /usr/include/sys/socket.h:53: error: conflicting types for
> 'getservbyname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:557:
> error: previous declaration of 'getservbyname' was here
> /usr/include/sys/socket.h:53: error: conflicting types for
> 'getservbyname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:557:
> error: previous declaration of 'getservbyname' was here In
> file included from compat/../git-compat-util.h:135,
> from compat/cygwin.c:9:
> /usr/include/sys/select.h:31: error: conflicting types for 'select'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:632:
> error: previous declaration of 'select' was here
> /usr/include/sys/select.h:31: error: conflicting types for 'select'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:632:
> error: previous declaration of 'select' was here In file
> included from /usr/include/netinet/in.h:14,
> from compat/../git-compat-util.h:137,
> from compat/cygwin.c:9:
> /usr/include/cygwin/in.h:30: error: parse error before
> numeric constant
> /usr/include/cygwin/in.h:35: error: parse error before
> numeric constant
> /usr/include/cygwin/in.h:37: error: parse error before
> numeric constant
> /usr/include/cygwin/in.h:76: error: parse error before
> numeric constant
> /usr/include/cygwin/in.h:115: error: redefinition of `struct in_addr'
> /usr/include/cygwin/in.h:116: error: parse error before '.' token
> /usr/include/cygwin/in.h:184: error: redefinition of `struct
> sockaddr_in'
> In file included from /usr/include/cygwin/in.h:250,
> from /usr/include/netinet/in.h:14,
> from compat/../git-compat-util.h:137,
> from compat/cygwin.c:9:
> /usr/include/asm/byteorder.h:26: error: conflicting types for 'ntohl'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:629:
> error: previous declaration of 'ntohl' was here
> /usr/include/asm/byteorder.h:26: error: conflicting types for 'ntohl'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:629:
> error: previous declaration of 'ntohl' was here
> /usr/include/asm/byteorder.h:27: error: conflicting types for 'ntohs'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:631:
> error: previous declaration of 'ntohs' was here
> /usr/include/asm/byteorder.h:27: error: conflicting types for 'ntohs'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:631:
> error: previous declaration of 'ntohs' was here
> /usr/include/asm/byteorder.h:28: error: conflicting types for 'htonl'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:628:
> error: previous declaration of 'htonl' was here
> /usr/include/asm/byteorder.h:28: error: conflicting types for 'htonl'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:628:
> error: previous declaration of 'htonl' was here
> /usr/include/asm/byteorder.h:29: error: conflicting types for 'htons'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:630:
> error: previous declaration of 'htons' was here
> /usr/include/asm/byteorder.h:29: error: conflicting types for 'htons'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:630:
> error: previous declaration of 'htons' was here In file
> included from compat/../git-compat-util.h:139,
> from compat/cygwin.c:9:
> /usr/include/arpa/inet.h:22: error: conflicting types for 'inet_addr'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:544:
> error: previous declaration of 'inet_addr' was here
> /usr/include/arpa/inet.h:22: error: conflicting types for 'inet_addr'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:544:
> error: previous declaration of 'inet_addr' was here
> /usr/include/arpa/inet.h:28: error: conflicting types for 'inet_ntoa'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:545:
> error: previous declaration of 'inet_ntoa' was here
> /usr/include/arpa/inet.h:28: error: conflicting types for 'inet_ntoa'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:545:
> error: previous declaration of 'inet_ntoa' was here In file
> included from compat/../git-compat-util.h:140,
> from compat/cygwin.c:9:
> /usr/include/netdb.h:79: error: redefinition of `struct hostent'
> /usr/include/netdb.h:93: error: redefinition of `struct netent'
> /usr/include/netdb.h:100: error: redefinition of `struct servent'
> /usr/include/netdb.h:108: error: redefinition of `struct protoent'
> /usr/include/netdb.h:139: error: conflicting types for
> 'WSAGetLastError'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:594:
> error: previous declaration of 'WSAGetLastError' was here
> /usr/include/netdb.h:139: error: conflicting types for
> 'WSAGetLastError'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:594:
> error: previous declaration of 'WSAGetLastError' was here
> /usr/include/netdb.h:192: error: conflicting types for 'gethostbyaddr'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:554:
> error: previous declaration of 'gethostbyaddr' was here
> /usr/include/netdb.h:192: error: conflicting types for 'gethostbyaddr'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:554:
> error: previous declaration of 'gethostbyaddr' was here
> /usr/include/netdb.h:193: error: conflicting types for 'gethostbyname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:555:
> error: previous declaration of 'gethostbyname' was here
> /usr/include/netdb.h:193: error: conflicting types for 'gethostbyname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:555:
> error: previous declaration of 'gethostbyname' was here
> /usr/include/netdb.h:199: error: conflicting types for
> 'getprotobyname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:559:
> error: previous declaration of 'getprotobyname' was here
> /usr/include/netdb.h:199: error: conflicting types for
> 'getprotobyname'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:559:
> error: previous declaration of 'getprotobyname' was here
> /usr/include/netdb.h:200: error: conflicting types for
> 'getprotobynumber'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:558:
> error: previous declaration of 'getprotobynumber' was here
> /usr/include/netdb.h:200: error: conflicting types for
> 'getprotobynumber'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:558:
> error: previous declaration of 'getprotobynumber' was here
> /usr/include/netdb.h:203: error: conflicting types for 'getservbyport'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:556:
> error: previous declaration of 'getservbyport' was here
> /usr/include/netdb.h:203: error: conflicting types for 'getservbyport'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
insock2.h:556:
> error: previous declaration of 'getservbyport' was here
> Makefile:2384: recipe for target `compat/cygwin.o' failed
> make: *** [compat/cygwin.o] Error 1
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 3:37 ` Jason Pyeron
@ 2013-01-06 4:22 ` Jason Pyeron
0 siblings, 0 replies; 45+ messages in thread
From: Jason Pyeron @ 2013-01-06 4:22 UTC (permalink / raw)
To: git
> -----Original Message-----
> From: Jason Pyeron
> Sent: Saturday, January 05, 2013 22:38
>
>
> > Stephen & Linda Smith
> > Sent: Saturday, January 05, 2013 21:05
> >
> > Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message
> states that
> > the macro was being renamed for clarity. The patch also changes a
> > define.
>
> Was it the commit before
> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was
> it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
> am doing a cygwin update presently to look at it.
>
> >
> > This change causes the code to not compile on cygwin 1.7.14.
> >
> > I narrowed the problem to this patch by bisecting commits between
> > v1.8.0 and
> > 1.8.1
> >
> > Here is the error sequence:
Cannot reproduce on head and current cygwin, more details please.
> >
> > CC compat/cygwin.o
> > In file included from compat/../git-compat-util.h:90,
> > from compat/cygwin.c:9:
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:103:2:
> > warning: #warning "fd_set and associated macros have been
> > defined in sys/types.
> > This may cause runtime problems with W32 sockets"
> > In file included from /usr/include/sys/socket.h:16,
> > from compat/../git-compat-util.h:131,
> > from compat/cygwin.c:9:
> > /usr/include/cygwin/socket.h:29: error: redefinition of `struct
> > sockaddr'
> > /usr/include/cygwin/socket.h:41: error: redefinition of `struct
> > sockaddr_storage'
> > In file included from /usr/include/sys/socket.h:16,
> > from compat/../git-compat-util.h:131,
> > from compat/cygwin.c:9:
> > /usr/include/cygwin/socket.h:59: error: redefinition of `struct
> > linger'
> > In file included from compat/../git-compat-util.h:131,
> > from compat/cygwin.c:9:
> > /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:536:
> > error: previous declaration of 'accept' was here
> > /usr/include/sys/socket.h:30: error: conflicting types for 'accept'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:536:
jpyeron@porsche /projects/git/git
$ make && uname -a && git status && git log --oneline | head -n1
GEN perl/PM.stamp
SUBDIR gitweb
SUBDIR ../
make[2]: `GIT-VERSION-FILE' is up to date.
GEN git-instaweb
BUILTIN all
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Nothing to be done for `all'.
SUBDIR perl
SUBDIR git_remote_helpers
SUBDIR templates
CYGWIN_NT-5.2-WOW64 porsche 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
# On branch master
nothing to commit (working directory clean)
3e293fb Update draft release notes to 1.8.2
> > error: previous declaration of 'accept' was here
> > /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:537:
> > error: previous declaration of 'bind' was here
> > /usr/include/sys/socket.h:32: error: conflicting types for 'bind'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:537:
> > error: previous declaration of 'bind' was here
> > /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:539:
> > error: previous declaration of 'connect' was here
> > /usr/include/sys/socket.h:33: error: conflicting types for 'connect'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:539:
> > error: previous declaration of 'connect' was here
> > /usr/include/sys/socket.h:34: error: conflicting types for
> > 'getpeername'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:541:
> > error: previous declaration of 'getpeername' was here
> > /usr/include/sys/socket.h:34: error: conflicting types for
> > 'getpeername'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:541:
> > error: previous declaration of 'getpeername' was here
> > /usr/include/sys/socket.h:35: error: conflicting types for
> > 'getsockname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:542:
> > error: previous declaration of 'getsockname' was here
> > /usr/include/sys/socket.h:35: error: conflicting types for
> > 'getsockname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:542:
> > error: previous declaration of 'getsockname' was here
> > /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:546:
> > error: previous declaration of 'listen' was here
> > /usr/include/sys/socket.h:36: error: conflicting types for 'listen'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:546:
> > error: previous declaration of 'listen' was here
> > /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:547:
> > error: previous declaration of 'recv' was here
> > /usr/include/sys/socket.h:37: error: conflicting types for 'recv'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:547:
> > error: previous declaration of 'recv' was here
> > /usr/include/sys/socket.h:39: error: conflicting types for
> 'recvfrom'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:548:
> > error: previous declaration of 'recvfrom' was here
> > /usr/include/sys/socket.h:39: error: conflicting types for
> 'recvfrom'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:548:
> > error: previous declaration of 'recvfrom' was here
> > /usr/include/sys/socket.h:41: error: conflicting types for 'send'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:549:
> > error: previous declaration of 'send' was here
> > /usr/include/sys/socket.h:41: error: conflicting types for 'send'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:549:
> > error: previous declaration of 'send' was here
> > /usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:550:
> > error: previous declaration of 'sendto' was here
> > /usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:550:
> > error: previous declaration of 'sendto' was here
> > /usr/include/sys/socket.h:46: error: conflicting types for
> > 'setsockopt'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:551:
> > error: previous declaration of 'setsockopt' was here
> > /usr/include/sys/socket.h:46: error: conflicting types for
> > 'setsockopt'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:551:
> > error: previous declaration of 'setsockopt' was here
> > /usr/include/sys/socket.h:48: error: conflicting types for
> > 'getsockopt'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:543:
> > error: previous declaration of 'getsockopt' was here
> > /usr/include/sys/socket.h:48: error: conflicting types for
> > 'getsockopt'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:543:
> > error: previous declaration of 'getsockopt' was here
> > /usr/include/sys/socket.h:49: error: conflicting types for
> 'shutdown'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:552:
> > error: previous declaration of 'shutdown' was here
> > /usr/include/sys/socket.h:49: error: conflicting types for
> 'shutdown'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:552:
> > error: previous declaration of 'shutdown' was here
> > /usr/include/sys/socket.h:50: error: conflicting types for 'socket'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:553:
> > error: previous declaration of 'socket' was here
> > /usr/include/sys/socket.h:50: error: conflicting types for 'socket'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:553:
> > error: previous declaration of 'socket' was here
> > /usr/include/sys/socket.h:53: error: conflicting types for
> > 'getservbyname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:557:
> > error: previous declaration of 'getservbyname' was here
> > /usr/include/sys/socket.h:53: error: conflicting types for
> > 'getservbyname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:557:
> > error: previous declaration of 'getservbyname' was here In file
> > included from compat/../git-compat-util.h:135,
> > from compat/cygwin.c:9:
> > /usr/include/sys/select.h:31: error: conflicting types for 'select'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:632:
> > error: previous declaration of 'select' was here
> > /usr/include/sys/select.h:31: error: conflicting types for 'select'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:632:
> > error: previous declaration of 'select' was here In file
> included from
> > /usr/include/netinet/in.h:14,
> > from compat/../git-compat-util.h:137,
> > from compat/cygwin.c:9:
> > /usr/include/cygwin/in.h:30: error: parse error before numeric
> > constant
> > /usr/include/cygwin/in.h:35: error: parse error before numeric
> > constant
> > /usr/include/cygwin/in.h:37: error: parse error before numeric
> > constant
> > /usr/include/cygwin/in.h:76: error: parse error before numeric
> > constant
> > /usr/include/cygwin/in.h:115: error: redefinition of
> `struct in_addr'
> > /usr/include/cygwin/in.h:116: error: parse error before '.' token
> > /usr/include/cygwin/in.h:184: error: redefinition of `struct
> > sockaddr_in'
> > In file included from /usr/include/cygwin/in.h:250,
> > from /usr/include/netinet/in.h:14,
> > from compat/../git-compat-util.h:137,
> > from compat/cygwin.c:9:
> > /usr/include/asm/byteorder.h:26: error: conflicting types
> for 'ntohl'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:629:
> > error: previous declaration of 'ntohl' was here
> > /usr/include/asm/byteorder.h:26: error: conflicting types
> for 'ntohl'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:629:
> > error: previous declaration of 'ntohl' was here
> > /usr/include/asm/byteorder.h:27: error: conflicting types
> for 'ntohs'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:631:
> > error: previous declaration of 'ntohs' was here
> > /usr/include/asm/byteorder.h:27: error: conflicting types
> for 'ntohs'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:631:
> > error: previous declaration of 'ntohs' was here
> > /usr/include/asm/byteorder.h:28: error: conflicting types
> for 'htonl'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:628:
> > error: previous declaration of 'htonl' was here
> > /usr/include/asm/byteorder.h:28: error: conflicting types
> for 'htonl'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:628:
> > error: previous declaration of 'htonl' was here
> > /usr/include/asm/byteorder.h:29: error: conflicting types
> for 'htons'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:630:
> > error: previous declaration of 'htons' was here
> > /usr/include/asm/byteorder.h:29: error: conflicting types
> for 'htons'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:630:
> > error: previous declaration of 'htons' was here In file
> included from
> > compat/../git-compat-util.h:139,
> > from compat/cygwin.c:9:
> > /usr/include/arpa/inet.h:22: error: conflicting types for
> 'inet_addr'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:544:
> > error: previous declaration of 'inet_addr' was here
> > /usr/include/arpa/inet.h:22: error: conflicting types for
> 'inet_addr'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:544:
> > error: previous declaration of 'inet_addr' was here
> > /usr/include/arpa/inet.h:28: error: conflicting types for
> 'inet_ntoa'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:545:
> > error: previous declaration of 'inet_ntoa' was here
> > /usr/include/arpa/inet.h:28: error: conflicting types for
> 'inet_ntoa'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:545:
> > error: previous declaration of 'inet_ntoa' was here In file
> included
> > from compat/../git-compat-util.h:140,
> > from compat/cygwin.c:9:
> > /usr/include/netdb.h:79: error: redefinition of `struct hostent'
> > /usr/include/netdb.h:93: error: redefinition of `struct netent'
> > /usr/include/netdb.h:100: error: redefinition of `struct servent'
> > /usr/include/netdb.h:108: error: redefinition of `struct protoent'
> > /usr/include/netdb.h:139: error: conflicting types for
> > 'WSAGetLastError'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:594:
> > error: previous declaration of 'WSAGetLastError' was here
> > /usr/include/netdb.h:139: error: conflicting types for
> > 'WSAGetLastError'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:594:
> > error: previous declaration of 'WSAGetLastError' was here
> > /usr/include/netdb.h:192: error: conflicting types for
> 'gethostbyaddr'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:554:
> > error: previous declaration of 'gethostbyaddr' was here
> > /usr/include/netdb.h:192: error: conflicting types for
> 'gethostbyaddr'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:554:
> > error: previous declaration of 'gethostbyaddr' was here
> > /usr/include/netdb.h:193: error: conflicting types for
> 'gethostbyname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:555:
> > error: previous declaration of 'gethostbyname' was here
> > /usr/include/netdb.h:193: error: conflicting types for
> 'gethostbyname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:555:
> > error: previous declaration of 'gethostbyname' was here
> > /usr/include/netdb.h:199: error: conflicting types for
> > 'getprotobyname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:559:
> > error: previous declaration of 'getprotobyname' was here
> > /usr/include/netdb.h:199: error: conflicting types for
> > 'getprotobyname'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:559:
> > error: previous declaration of 'getprotobyname' was here
> > /usr/include/netdb.h:200: error: conflicting types for
> > 'getprotobynumber'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:558:
> > error: previous declaration of 'getprotobynumber' was here
> > /usr/include/netdb.h:200: error: conflicting types for
> > 'getprotobynumber'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:558:
> > error: previous declaration of 'getprotobynumber' was here
> > /usr/include/netdb.h:203: error: conflicting types for
> 'getservbyport'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:556:
> > error: previous declaration of 'getservbyport' was here
> > /usr/include/netdb.h:203: error: conflicting types for
> 'getservbyport'
> > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w
> insock2.h:556:
> > error: previous declaration of 'getservbyport' was here
> > Makefile:2384: recipe for target `compat/cygwin.o' failed
> > make: *** [compat/cygwin.o] Error 1
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> git" in the
> > body of a message to majordomo@vger.kernel.org More
> majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> >
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 2:04 Version 1.8.1 does not compile on Cygwin 1.7.14 Stephen & Linda Smith
2013-01-06 3:37 ` Jason Pyeron
@ 2013-01-06 6:20 ` Stephen & Linda Smith
2013-01-06 6:29 ` Jason Pyeron
1 sibling, 1 reply; 45+ messages in thread
From: Stephen & Linda Smith @ 2013-01-06 6:20 UTC (permalink / raw)
To: git, jpyeron
> Was it the commit before
> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was
> it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
> am doing a cygwin update presently to look at it.
Since the email earlier today, I had blown away the directory. I just now
did the following
git clone https://github.com/git/git.git git-src && cd git-src && make all
... The make errored out as before
git co 9fca6c && make all
... The make errored out as before
git co 9fca6c^ && make all
... and this compiles to completion
CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 i686 Cygwin
What else can I do to test this out (I will get a current cygwin tomorrow to
use in a test).
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 6:20 ` Stephen & Linda Smith
@ 2013-01-06 6:29 ` Jason Pyeron
2013-01-06 7:23 ` Torsten Bögershausen
0 siblings, 1 reply; 45+ messages in thread
From: Jason Pyeron @ 2013-01-06 6:29 UTC (permalink / raw)
To: git
> -----Original Message-----
> From: Stephen & Linda Smith
> Sent: Sunday, January 06, 2013 1:21
>
> > Was it the commit before
> > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it
> > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
> am doing a
> > cygwin update presently to look at it.
>
> Since the email earlier today, I had blown away the
> directory. I just now
> did the following
>
> git clone https://github.com/git/git.git git-src && cd
> git-src && make all
> ... The make errored out as before
>
No error for me.
> git co 9fca6c && make all
> ... The make errored out as before
No error for me.
>
> git co 9fca6c^ && make all
> ... and this compiles to completion
>
> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
> i686 Cygwin
This is old, do you have the luxury of updating it?
>
> What else can I do to test this out (I will get a current
> cygwin tomorrow to use in a test).
I would also check to see if your devel packages are up to date too.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 6:29 ` Jason Pyeron
@ 2013-01-06 7:23 ` Torsten Bögershausen
2013-01-06 9:32 ` Jonathan Nieder
0 siblings, 1 reply; 45+ messages in thread
From: Torsten Bögershausen @ 2013-01-06 7:23 UTC (permalink / raw)
To: Jason Pyeron; +Cc: git
On 06.01.13 07:29, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Stephen & Linda Smith
>> Sent: Sunday, January 06, 2013 1:21
>>
>>> Was it the commit before
>>> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it
>>> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
>> am doing a
>>> cygwin update presently to look at it.
>>
>> Since the email earlier today, I had blown away the
>> directory. I just now
>> did the following
>>
>> git clone https://github.com/git/git.git git-src && cd
>> git-src && make all
>> ... The make errored out as before
>>
>
> No error for me.
>
>> git co 9fca6c && make all
>> ... The make errored out as before
>
> No error for me.
>
>>
>> git co 9fca6c^ && make all
>> ... and this compiles to completion
>>
>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
>> i686 Cygwin
>
> This is old, do you have the luxury of updating it?
>
>>
>> What else can I do to test this out (I will get a current
>> cygwin tomorrow to use in a test).
>
> I would also check to see if your devel packages are up to date too.
You can either upgrade to cygwin 1.17 or higher.
Or, if that is really not possible (because you are sitting on a production machine,
where no changes are allowed),
You can enable this in Makefile:
CYGWIN_V15_WIN32API = YesPlease
HTH
/Torsten
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 7:23 ` Torsten Bögershausen
@ 2013-01-06 9:32 ` Jonathan Nieder
2013-01-06 9:42 ` Torsten Bögershausen
0 siblings, 1 reply; 45+ messages in thread
From: Jonathan Nieder @ 2013-01-06 9:32 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Stephen & Linda Smith, Jason Pyeron, git, Mark Levedahl
Hi,
Torsten Bögershausen wrote:
>> Stephen & Linda Smith wrote:
>>> git co 9fca6c && make all
>>> ... The make errored out as before
[...]
>>> git co 9fca6c^ && make all
>>> ... and this compiles to completion
>>>
>>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
>>> i686 Cygwin
[...]
> You can either upgrade to cygwin 1.17 or higher.
> Or, if that is really not possible (because you are sitting on a production machine,
> where no changes are allowed),
>
> You can enable this in Makefile:
> CYGWIN_V15_WIN32API = YesPlease
What I don't understand is why commit 9fca6c would have had any
effect at all. Since 1.7.14 doesn't match /^1\.[1-6]\./, wouldn't
the setting to avoid including <sys/stat.h> and <sys/errno.h> be
unset both before and after that commit?
Stephen, what is the content of your config.mak?
Curious,
Jonathan
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 9:32 ` Jonathan Nieder
@ 2013-01-06 9:42 ` Torsten Bögershausen
2013-01-06 9:57 ` Jonathan Nieder
0 siblings, 1 reply; 45+ messages in thread
From: Torsten Bögershausen @ 2013-01-06 9:42 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Torsten Bögershausen, Stephen & Linda Smith,
Jason Pyeron, git, Mark Levedahl
On 06.01.13 10:32, Jonathan Nieder wrote:
> Hi,
>
> Torsten Bögershausen wrote:
>>> Stephen & Linda Smith wrote:
>
>>>> git co 9fca6c && make all
>>>> ... The make errored out as before
> [...]
>>>> git co 9fca6c^ && make all
>>>> ... and this compiles to completion
>>>>
>>>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
>>>> i686 Cygwin
> [...]
>> You can either upgrade to cygwin 1.17 or higher.
>> Or, if that is really not possible (because you are sitting on a production machine,
>> where no changes are allowed),
>>
>> You can enable this in Makefile:
>> CYGWIN_V15_WIN32API = YesPlease
>
> What I don't understand is why commit 9fca6c would have had any
> effect at all. Since 1.7.14 doesn't match /^1\.[1-6]\./, wouldn't
> the setting to avoid including <sys/stat.h> and <sys/errno.h> be
> unset both before and after that commit?
>
> Stephen, what is the content of your config.mak?
>
> Curious,
> Jonathan
The short version:
Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
The change in cygwin came in in 1.7.17,
(and from that version of cygwin we need commit 9fca6c to compile git)
Currently we can not compile git under cygwin 1.7.1 .. 1.7.16 :-(
As "everybody" running cygwin 1.7 seems to update to the latest,
I don't know if we want to improve the Makefile to enable
CYGWIN_V15_WIN32API = YesPlease
for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
/Torsten
http://git.661346.n2.nabble.com/PATCH-Rename-V15-MINGW-HEADERS-into-CYGWIN-OLD-WINSOCK-HEADERS-td7571449.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 9:42 ` Torsten Bögershausen
@ 2013-01-06 9:57 ` Jonathan Nieder
2013-01-06 11:48 ` Mark Levedahl
0 siblings, 1 reply; 45+ messages in thread
From: Jonathan Nieder @ 2013-01-06 9:57 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Stephen & Linda Smith, Jason Pyeron, git, Mark Levedahl,
Eric Blake
Torsten Bögershausen wrote:
> The short version:
> Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
[...]
> I don't know if we want to improve the Makefile to enable
> CYGWIN_V15_WIN32API = YesPlease
> for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
Confusing. Sounds like the condition in 380a4d92 (Update cygwin.c for
new mingw-64 win32 api headers, 2012-11-11) was too strict and the
Makefile should say something like
# Cygwin versions up to 1.7.16 used the same headers
# as Cygwin 1.5.
ifeq ($(shell expr "$(uname_R)" : '1\.7\.[0-9]$$'),5)
CYGWIN_V15_WIN32API = YesPlease
endif
ifeq ($(shell expr "$(uname_R)" : '1\.7\.1[0-6]$$'),6)
CYGWIN_V15_WIN32API = YesPlease
endif
ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)
CYGWIN_V15_WIN32API = YesPlease
...
endif
Is that right?
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 9:57 ` Jonathan Nieder
@ 2013-01-06 11:48 ` Mark Levedahl
2013-01-06 12:09 ` Jonathan Nieder
0 siblings, 1 reply; 45+ messages in thread
From: Mark Levedahl @ 2013-01-06 11:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Torsten Bögershausen, Stephen & Linda Smith,
Jason Pyeron, git, Eric Blake
On 01/06/2013 04:57 AM, Jonathan Nieder wrote:
> Torsten Bögershausen wrote:
>
>> The short version:
>> Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
> [...]
>> I don't know if we want to improve the Makefile to enable
>> CYGWIN_V15_WIN32API = YesPlease
>> for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
>>
You are conflating the cygwin dll version with the win32 api version.
These are independent packages (just as the kernel and glibc packages
are independent on linux) and do not share a version number. However,
the newer win32api is provided only for the current cygwin release
series, which can be reliably identified by having dll version 1.7.x,
while the older frozen releases (dll versions 1.6.x from redhat, 1.5.x
open source) still have the older api as no updates are being made for
the legacy version(s).
Cygwin does not version the win32api in any useful way: the package
names changed completely, for instance, and there is no macro defined
from the header files to indicate a version number. Also, there is no
supported way to now install the older version: the only supported
configuration is with the *current* win32api: multiple packages depend
by name on the current win32api package, so the installer will insist
upon its installation.
So the solution is to update the cygwin installation. Really. If you
don't believe me, try asking on the cygwin mailing list. They only
support the current releases, not obsolete packages, and the older
win32api is explicitly obsolete.
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 11:48 ` Mark Levedahl
@ 2013-01-06 12:09 ` Jonathan Nieder
2013-01-06 14:09 ` Stephen & Linda Smith
2013-01-06 19:54 ` Junio C Hamano
0 siblings, 2 replies; 45+ messages in thread
From: Jonathan Nieder @ 2013-01-06 12:09 UTC (permalink / raw)
To: Mark Levedahl
Cc: Torsten Bögershausen, Stephen & Linda Smith,
Jason Pyeron, git, Eric Blake
Mark Levedahl wrote:
> However, the newer
> win32api is provided only for the current cygwin release series, which can
> be reliably identified by having dll version 1.7.x, while the older frozen
> releases (dll versions 1.6.x from redhat, 1.5.x open source) still have the
> older api as no updates are being made for the legacy version(s).
Ah. That makes sense, thanks.
(For the future, if we wanted to diagnose an out-of-date win32api and
print a helpful message, I guess cygcheck would be the command to use.)
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 12:09 ` Jonathan Nieder
@ 2013-01-06 14:09 ` Stephen & Linda Smith
2013-01-06 19:54 ` Junio C Hamano
1 sibling, 0 replies; 45+ messages in thread
From: Stephen & Linda Smith @ 2013-01-06 14:09 UTC (permalink / raw)
To: ischis2
Cc: Jonathan Nieder, Mark Levedahl, Jason Pyeron, Eric Blake, git,
Torsten Bögershausen
On Sunday, January 06, 2013 04:09:17 AM Jonathan Nieder wrote:
> Mark Levedahl wrote:
> > However, the
> > newer
> >
> > win32api is provided only for the current cygwin release series, which can
> > be reliably identified by having dll version 1.7.x, while the older frozen
> > releases (dll versions 1.6.x from redhat, 1.5.x open source) still have
> > the
> > older api as no updates are being made for the legacy version(s).
>
> Ah. That makes sense, thanks.
>
> (For the future, if we wanted to diagnose an out-of-date win32api and
> print a helpful message, I guess cygcheck would be the command to use.)
Thank you for the information. I will update my cygwin installation.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 12:09 ` Jonathan Nieder
2013-01-06 14:09 ` Stephen & Linda Smith
@ 2013-01-06 19:54 ` Junio C Hamano
2013-01-06 20:51 ` Torsten Bögershausen
` (2 more replies)
1 sibling, 3 replies; 45+ messages in thread
From: Junio C Hamano @ 2013-01-06 19:54 UTC (permalink / raw)
To: Mark Levedahl
Cc: Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, git, Eric Blake
Jonathan Nieder <jrnieder@gmail.com> writes:
> Mark Levedahl wrote:
>
>> However, the newer
>> win32api is provided only for the current cygwin release series, which can
>> be reliably identified by having dll version 1.7.x, while the older frozen
>> releases (dll versions 1.6.x from redhat, 1.5.x open source) still have the
>> older api as no updates are being made for the legacy version(s).
>
> Ah. That makes sense, thanks.
>
> (For the future, if we wanted to diagnose an out-of-date win32api and
> print a helpful message, I guess cygcheck would be the command to use.)
Hmph, so we might see somebody who cares about Cygwin to come up
with a solution based on cygcheck (not on uname) to update this
part, perhaps on top of Peff's "split default settings based on
uname into separate file" patch?
If I understood what Mark and Torsten wrote correctly, you will have
the new win32api if you install 1.7.17 (or newer) from scratch, but
if you are on older 1.7.x then you can update the win32api part as a
package update (as opposed to the whole-system upgrade). A test
based on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
installation has a newer win32api because the user updated it from
the package (hence the user should not define CYGWIN_V15_WIN32API).
Am I on the same page as you guys, or am I still behind?
In the meantime, perhaps we would need something like this?
diff --git a/Makefile b/Makefile
index 8e225ca..b45b06d 100644
--- a/Makefile
+++ b/Makefile
@@ -281,6 +281,9 @@ all::
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
#
+# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older than
+# 1.7.x (this typically is true on Cygwin older than 1.7.17)
+#
# Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
# user.
#
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 19:54 ` Junio C Hamano
@ 2013-01-06 20:51 ` Torsten Bögershausen
2013-01-06 21:34 ` Mark Levedahl
2013-01-06 21:09 ` Mark Levedahl
2013-01-06 22:16 ` Mark Levedahl
2 siblings, 1 reply; 45+ messages in thread
From: Torsten Bögershausen @ 2013-01-06 20:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mark Levedahl, Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, git, Eric Blake
On 06.01.13 20:54, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Mark Levedahl wrote:
>>
>>> However, the newer
>>> win32api is provided only for the current cygwin release series, which can
>>> be reliably identified by having dll version 1.7.x, while the older frozen
>>> releases (dll versions 1.6.x from redhat, 1.5.x open source) still have the
>>> older api as no updates are being made for the legacy version(s).
>>
>> Ah. That makes sense, thanks.
>>
>> (For the future, if we wanted to diagnose an out-of-date win32api and
>> print a helpful message, I guess cygcheck would be the command to use.)
>
> Hmph, so we might see somebody who cares about Cygwin to come up
> with a solution based on cygcheck (not on uname) to update this
> part, perhaps on top of Peff's "split default settings based on
> uname into separate file" patch?
>
> If I understood what Mark and Torsten wrote correctly, you will have
> the new win32api if you install 1.7.17 (or newer) from scratch, but
> if you are on older 1.7.x then you can update the win32api part as a
> package update (as opposed to the whole-system upgrade). A test
> based on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> installation has a newer win32api because the user updated it from
> the package (hence the user should not define CYGWIN_V15_WIN32API).
>
> Am I on the same page as you guys, or am I still behind?
>
> In the meantime, perhaps we would need something like this?
>
>
> diff --git a/Makefile b/Makefile
> index 8e225ca..b45b06d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -281,6 +281,9 @@ all::
> #
> # Define NO_REGEX if you have no or inferior regex support in your C library.
> #
> +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older than
> +# 1.7.x (this typically is true on Cygwin older than 1.7.17)
> +#
> # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
> # user.
> #
Hm, I haven't understood the connection between the dll (cygwin1.dll ?)
which is used in runtime, and the header files which are used when compiling.
Are they updated at the same time when updating from 1.7.16 to 1.7.17 ?
Until I updated my cygwin 1.7 (following Marks recommendation) this did the trick for me:
+ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y)
+ CYGWIN_V15_WIN32API=YesPlease
+endif
As an alternative, would this be easier to read?
> +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 19:54 ` Junio C Hamano
2013-01-06 20:51 ` Torsten Bögershausen
@ 2013-01-06 21:09 ` Mark Levedahl
2013-01-06 21:33 ` Jason Pyeron
2013-01-06 21:35 ` Junio C Hamano
2013-01-06 22:16 ` Mark Levedahl
2 siblings, 2 replies; 45+ messages in thread
From: Mark Levedahl @ 2013-01-06 21:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, git, Eric Blake
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Mark Levedahl wrote:
>>
>>> However, the newer
>>> win32api is provided only for the current cygwin release series, which can
>>> be reliably identified by having dll version 1.7.x, while the older frozen
>>> releases (dll versions 1.6.x from redhat, 1.5.x open source) still have the
>>> older api as no updates are being made for the legacy version(s).
>> Ah. That makes sense, thanks.
>>
>> (For the future, if we wanted to diagnose an out-of-date win32api and
>> print a helpful message, I guess cygcheck would be the command to use.)
> Hmph, so we might see somebody who cares about Cygwin to come up
> with a solution based on cygcheck (not on uname) to update this
> part, perhaps on top of Peff's "split default settings based on
> uname into separate file" patch?
>
> If I understood what Mark and Torsten wrote correctly, you will have
> the new win32api if you install 1.7.17 (or newer) from scratch, but
> if you are on older 1.7.x then you can update the win32api part as a
> package update (as opposed to the whole-system upgrade). A test
> based on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> installation has a newer win32api because the user updated it from
> the package (hence the user should not define CYGWIN_V15_WIN32API).
>
> Am I on the same page as you guys, or am I still behind?
>
> In the meantime, perhaps we would need something like this?
>
>
> diff --git a/Makefile b/Makefile
> index 8e225ca..b45b06d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -281,6 +281,9 @@ all::
> #
> # Define NO_REGEX if you have no or inferior regex support in your C library.
> #
> +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api dll older than
> +# 1.7.x (this typically is true on Cygwin older than 1.7.17)
> +#
> # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
> # user.
> #
>
Looking at a current setup.ini, the obsolete win32 api is a single
package "w32api" with last version 3.17-2, and is now replaced by the
new win32 api is in two packages, "w32api-headers" + "w32api-runtime",
both at version 3.0b_svn5496-1. If setup.exe updated an older
installation of w32api, the old package is not deleted, but replaced by
a special "empty" package with (as of today) version 9999-1. Note that
all of this could change at any time. Also, note that the new w32api
packages have version numbers that are lower than the older obsoleted
version.
Running "cygcheck -c w32api w32api-headers w32api-runtime" on one
machine gives
Cygwin Package Information
Package Version Status
w32api 9999-1 OK
w32api-headers 3.0b_svn5496-1 OK
w32api-runtime 3.0b_svn5496-1 OK
So now, what do folks propose checking for?
a) w32api is installed? Nope - the package is not "removed", it was
updated to a special empty version to delete its former contents, but a
new fresh installation won't have this.
b) w32api-headers is installed? Nope - what happens on the next repackaging?
c) w32api version is 9999-1? Maybe, but that number could change.
etc.
There is no documented, reliable, future-proof, method of determining
the installed w32api version on Cygwin. There are many things that can
be done that will work frequently, except when they won't. I really
think the only sane thing is to follow the guidance of the Cygwin
developers: the only supported configuration is that which the current
setup.exe produces, and in the case of problems, if the installation is
not up to date then updating is the first required action.
So, in the makefile, you might add:
+# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not
+# using the current w32api packages. But, the recommended approach is to
+# update your installation if compilation errors occur.
+#
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 21:09 ` Mark Levedahl
@ 2013-01-06 21:33 ` Jason Pyeron
2013-01-06 21:35 ` Junio C Hamano
1 sibling, 0 replies; 45+ messages in thread
From: Jason Pyeron @ 2013-01-06 21:33 UTC (permalink / raw)
To: git
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Mark Levedahl
> Sent: Sunday, January 06, 2013 16:10
> To: Junio C Hamano
> Cc: Jonathan Nieder; Torsten Bögershausen; Stephen & Linda
> Smith; Jason Pyeron; git@vger.kernel.org; Eric Blake
> Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14
>
> On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> > Jonathan Nieder <jrnieder@gmail.com> writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>
> However,
> >>> the newer win32api is provided only for the current
> cygwin release
> >>> series, which can be reliably identified by having dll version
> >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from
> >>> redhat, 1.5.x open source) still have the older api as no
> updates are being made for the legacy version(s).
> >> Ah. That makes sense, thanks.
> >>
> >> (For the future, if we wanted to diagnose an out-of-date
> win32api and
> >> print a helpful message, I guess cygcheck would be the command to
> >> use.)
> > Hmph, so we might see somebody who cares about Cygwin to
> come up with
> > a solution based on cygcheck (not on uname) to update this part,
> > perhaps on top of Peff's "split default settings based on
> uname into
> > separate file" patch?
> >
> > If I understood what Mark and Torsten wrote correctly, you
> will have
> > the new win32api if you install 1.7.17 (or newer) from
> scratch, but if
> > you are on older 1.7.x then you can update the win32api part as a
> > package update (as opposed to the whole-system upgrade). A
> test based
> > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> > installation has a newer win32api because the user updated
> it from the
> > package (hence the user should not define CYGWIN_V15_WIN32API).
> >
> > Am I on the same page as you guys, or am I still behind?
> >
> > In the meantime, perhaps we would need something like this?
> >
> >
> > diff --git a/Makefile b/Makefile
> > index 8e225ca..b45b06d 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -281,6 +281,9 @@ all::
> > #
> > # Define NO_REGEX if you have no or inferior regex
> support in your C library.
> > #
> > +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api
> dll older
> > +than # 1.7.x (this typically is true on Cygwin older than 1.7.17) #
> > # Define HAVE_DEV_TTY if your system can open /dev/tty to
> interact with the
> > # user.
> > #
> >
> Looking at a current setup.ini, the obsolete win32 api is a
> single package "w32api" with last version 3.17-2, and is now
> replaced by the new win32 api is in two packages,
> "w32api-headers" + "w32api-runtime", both at version
> 3.0b_svn5496-1. If setup.exe updated an older installation of
> w32api, the old package is not deleted, but replaced by a
> special "empty" package with (as of today) version 9999-1.
> Note that all of this could change at any time. Also, note
> that the new w32api packages have version numbers that are
> lower than the older obsoleted version.
I would not rely on that information as it is not designed to convey the
information the git build needs.
>
> Running "cygcheck -c w32api w32api-headers w32api-runtime" on
> one machine gives
>
> Cygwin Package Information
> Package Version Status
> w32api 9999-1 OK
> w32api-headers 3.0b_svn5496-1 OK
> w32api-runtime 3.0b_svn5496-1 OK
>
> So now, what do folks propose checking for?
> a) w32api is installed? Nope - the package is not "removed",
> it was updated to a special empty version to delete its
> former contents, but a new fresh installation won't have this.
> b) w32api-headers is installed? Nope - what happens on the
> next repackaging?
> c) w32api version is 9999-1? Maybe, but that number could change.
> etc.
This is what is typically done in a configure script by test compiling.
>
> There is no documented, reliable, future-proof, method of
> determining the installed w32api version on Cygwin. There are
> many things that can be done that will work frequently,
> except when they won't. I really think the only sane thing is
> to follow the guidance of the Cygwin
> developers: the only supported configuration is that which
> the current setup.exe produces, and in the case of problems,
> if the installation is not up to date then updating is the
> first required action.
>
> So, in the makefile, you might add:
>
> +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x
> but are not
> +# using the current w32api packages. But, the recommended
> approach is
> +to # update your installation if compilation errors occur.
> +#
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 20:51 ` Torsten Bögershausen
@ 2013-01-06 21:34 ` Mark Levedahl
0 siblings, 0 replies; 45+ messages in thread
From: Mark Levedahl @ 2013-01-06 21:34 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Junio C Hamano, Jonathan Nieder, Stephen & Linda Smith,
Jason Pyeron, git, Eric Blake
On 01/06/2013 03:51 PM, Torsten Bögershausen wrote:
> Hm, I haven't understood the connection between the dll (cygwin1.dll
> ?) which is used in runtime, and the header files which are used when
> compiling. Are they updated at the same time when updating from 1.7.16
> to 1.7.17 ? Until I updated my cygwin 1.7 (following Marks
> recommendation) this did the trick for me: +ifeq ($(shell grep mingw
> /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y) +
> CYGWIN_V15_WIN32API=YesPlease +endif As an alternative, would this be
> easier to read?
>> +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16
>
>
The cygwin distribution has a very large number of packages, each with
its own unique version number and update rhythm, just as in any linux
distro. There is no "cygwin version", just a version for each individual
package. So, "Cygwin version 1.7.16" is really nonsensical: there is
only cygwin.dll version 1.7.16. What folks are noticing is a
coincidence in the time when the cygwin dll package updated and when the
old w32api was obsoleted. uname -r reports the cygwin dll version, not
the version of any other package. Note that the cygwin api is "stable",
meaning a package compiled against the 1.7.1 dll will still run against
the current one: updating the cygwin dll does not require other packages
to update.
The only hard linkage here is that the Cygwin developers are maintaining
a legacy cygwin version (v1.5.x) as the newer dll series (v.1.7.x)
dropped support for all Windows versions predating (I think) WinXP. So,
someone on an old Windows version must use the legacy cygwin version
which has not been updated since the first v1.7 dll was released, nor
are there any plans by the developers to ever update the v1.5 packages.
Cygwin 1.5 lives in a separate distribution repository, with packages
frozen in time as of the last updates prior to going to v1.7 (packages
compiled against v1.7 will not run on v.1.5).
So, encountering a v1.5.x dll is a guarantee of using the older w32api
shared with the mingw project, rather than the current one now
maintained by the mingw64 project. However, a cygwin with any v1.7.x dll
could in theory have either w32api installed, or in theory yet another
newer one we don't know about yet. Unless and until the w32api
establishes a version number (independent of the Windows API version),
we have nothing reliable to use.
Therefore, if using the v1.7 series, *update*
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 21:09 ` Mark Levedahl
2013-01-06 21:33 ` Jason Pyeron
@ 2013-01-06 21:35 ` Junio C Hamano
2013-01-06 21:46 ` Jason Pyeron
2013-01-06 22:00 ` Mark Levedahl
1 sibling, 2 replies; 45+ messages in thread
From: Junio C Hamano @ 2013-01-06 21:35 UTC (permalink / raw)
To: Mark Levedahl
Cc: Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, git, Eric Blake
Thanks; so perhaps you can give me an OK to forge your S-o-b to the
following?
-- >8 --
From: Mark Levedahl <mlevedahl@gmail.com>
Date: Sun, 6 Jan 2013 11:56:33 -0800
Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
There is no documented, reliable, and future-proof method to
determine the installed w32api version on Cygwin. There are many
things that can be done that will work frequently, except when they
won't.
The only sane thing is to follow the guidance of the Cygwin
developers: the only supported configuration is that which the
current setup.exe produces, and in the case of problems, if the
installation is not up to date then updating is the first required
action.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 4d47af5..52e298a 100644
--- a/Makefile
+++ b/Makefile
@@ -273,6 +273,10 @@ all::
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
#
+# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not
+# using the current w32api packages. The recommended approach, however,
+# is to update your installation if compilation errors occur.
+#
# Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
# user.
#
--
1.8.1.302.g0f4eaa7
^ permalink raw reply related [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 21:35 ` Junio C Hamano
@ 2013-01-06 21:46 ` Jason Pyeron
2013-01-06 22:00 ` Mark Levedahl
1 sibling, 0 replies; 45+ messages in thread
From: Jason Pyeron @ 2013-01-06 21:46 UTC (permalink / raw)
To: git
> -----Original Message-----
> From: Junio C Hamano
> Sent: Sunday, January 06, 2013 16:36
>
> Thanks; so perhaps you can give me an OK to forge your S-o-b
> to the following?
I am personally fine with it, because cygwin is used by developers not
production systems and I expect my developers to upgrade their environment for
security fixes, etc.
If I ever had a situation where I am using git, in production, on cygwin, where
I could not upgrade I would effort to make a compile test based patch to the
make file to accommodate the issue.
>
> -- >8 --
> From: Mark Levedahl <mlevedahl@gmail.com>
> Date: Sun, 6 Jan 2013 11:56:33 -0800
> Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
>
> There is no documented, reliable, and future-proof method to
> determine the installed w32api version on Cygwin. There are
> many things that can be done that will work frequently,
> except when they won't.
>
> The only sane thing is to follow the guidance of the Cygwin
> developers: the only supported configuration is that which
> the current setup.exe produces, and in the case of problems,
> if the installation is not up to date then updating is the
> first required action.
>
> Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
> ---
> Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 4d47af5..52e298a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -273,6 +273,10 @@ all::
> #
> # Define NO_REGEX if you have no or inferior regex support
> in your C library.
> #
> +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x
> but are not
> +# using the current w32api packages. The recommended
> approach, however,
> +# is to update your installation if compilation errors occur.
> +#
> # Define HAVE_DEV_TTY if your system can open /dev/tty to
> interact with the # user.
> #
> --
> 1.8.1.302.g0f4eaa7
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 21:35 ` Junio C Hamano
2013-01-06 21:46 ` Jason Pyeron
@ 2013-01-06 22:00 ` Mark Levedahl
1 sibling, 0 replies; 45+ messages in thread
From: Mark Levedahl @ 2013-01-06 22:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, git, Eric Blake
On 01/06/2013 04:35 PM, Junio C Hamano wrote:
> Thanks; so perhaps you can give me an OK to forge your S-o-b to the
> following?
>
> -- >8 --
> From: Mark Levedahl <mlevedahl@gmail.com>
> Date: Sun, 6 Jan 2013 11:56:33 -0800
> Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
>
> There is no documented, reliable, and future-proof method to
> determine the installed w32api version on Cygwin. There are many
> things that can be done that will work frequently, except when they
> won't.
>
> The only sane thing is to follow the guidance of the Cygwin
> developers: the only supported configuration is that which the
> current setup.exe produces, and in the case of problems, if the
> installation is not up to date then updating is the first required
> action.
>
> Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
> ---
> Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 4d47af5..52e298a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -273,6 +273,10 @@ all::
> #
> # Define NO_REGEX if you have no or inferior regex support in your C library.
> #
> +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not
> +# using the current w32api packages. The recommended approach, however,
> +# is to update your installation if compilation errors occur.
> +#
> # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
> # user.
> #
Absolutely, that is ok by me.
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 19:54 ` Junio C Hamano
2013-01-06 20:51 ` Torsten Bögershausen
2013-01-06 21:09 ` Mark Levedahl
@ 2013-01-06 22:16 ` Mark Levedahl
2013-01-07 5:37 ` Jason Pyeron
2 siblings, 1 reply; 45+ messages in thread
From: Mark Levedahl @ 2013-01-06 22:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, git, Eric Blake
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Mark Levedahl wrote:
>>
>>> However, the newer
>>> win32api is provided only for the current cygwin release series, which can
>>> be reliably identified by having dll version 1.7.x, while the older frozen
>>> releases (dll versions 1.6.x from redhat, 1.5.x open source) still have the
>>> older api as no updates are being made for the legacy version(s).
>> Ah. That makes sense, thanks.
>>
>> (For the future, if we wanted to diagnose an out-of-date win32api and
>> print a helpful message, I guess cygcheck would be the command to use.)
> Hmph, so we might see somebody who cares about Cygwin to come up
> with a solution based on cygcheck (not on uname) to update this
> part, perhaps on top of Peff's "split default settings based on
> uname into separate file" patch?
>
> If I understood what Mark and Torsten wrote correctly, you will have
> the new win32api if you install 1.7.17 (or newer) from scratch, but
> if you are on older 1.7.x then you can update the win32api part as a
> package update (as opposed to the whole-system upgrade). A test
> based on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> installation has a newer win32api because the user updated it from
> the package (hence the user should not define CYGWIN_V15_WIN32API).
>
> Am I on the same page as you guys, or am I still behind?
>
> In the meantime, perhaps we would need something like this?
It's perhaps worth noting how we got into this mess. The problems have
their root in
adbc0b6b6e57c11ca49779d01f549260a920a97d
Cygwin's entire goal is a completely POSIX compliant environment running
under Windows. The above commit circumvents some of Cygwin's API
regarding stat/fstat to make things perhaps a bit faster, and definitely
not POSIX compliant (The commit message is wrong, the commit definitely
breaks POSIX compliance). That code is also what will not compile on
different w32api versions. It is curious: the Cygwin mailing list has
been absolutely silent since the w32api change was introduced last
summer, this is the only piece of code I am aware of that was broken by
the new headers, and of course the purpose of this code is to circumvent
the Cygwin API (and by extension, Cygwin project goals).
So, perhaps a better path forward is to disable / remove the above code
by default. (Those wanting a native Win32 git should just use the native
Win32 git).
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-06 22:16 ` Mark Levedahl
@ 2013-01-07 5:37 ` Jason Pyeron
2013-01-07 7:29 ` Junio C Hamano
0 siblings, 1 reply; 45+ messages in thread
From: Jason Pyeron @ 2013-01-07 5:37 UTC (permalink / raw)
To: git
> -----Original Message-----
> From: Mark Levedahl
> Sent: Sunday, January 06, 2013 17:17
>
> On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> > Jonathan Nieder <jrnieder@gmail.com> writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>
> However,
> >>> the newer win32api is provided only for the current
> cygwin release
> >>> series, which can be reliably identified by having dll version
> >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from
> >>> redhat, 1.5.x open source) still have the older api as no
> updates are being made for the legacy version(s).
> >> Ah. That makes sense, thanks.
> >>
> >> (For the future, if we wanted to diagnose an out-of-date
> win32api and
> >> print a helpful message, I guess cygcheck would be the command to
> >> use.)
> > Hmph, so we might see somebody who cares about Cygwin to
> come up with
> > a solution based on cygcheck (not on uname) to update this part,
> > perhaps on top of Peff's "split default settings based on
> uname into
> > separate file" patch?
> >
> > If I understood what Mark and Torsten wrote correctly, you
> will have
> > the new win32api if you install 1.7.17 (or newer) from
> scratch, but if
> > you are on older 1.7.x then you can update the win32api part as a
> > package update (as opposed to the whole-system upgrade). A
> test based
> > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> > installation has a newer win32api because the user updated
> it from the
> > package (hence the user should not define CYGWIN_V15_WIN32API).
> >
> > Am I on the same page as you guys, or am I still behind?
> >
> > In the meantime, perhaps we would need something like this?
>
> It's perhaps worth noting how we got into this mess. The
> problems have their root in
>
> adbc0b6b6e57c11ca49779d01f549260a920a97d
>
> Cygwin's entire goal is a completely POSIX compliant
> environment running under Windows. The above commit
> circumvents some of Cygwin's API regarding stat/fstat to make
> things perhaps a bit faster, and definitely not POSIX
Ug!
> compliant (The commit message is wrong, the commit definitely
> breaks POSIX compliance). That code is also what will not
> compile on different w32api versions. It is curious: the
> Cygwin mailing list has been absolutely silent since the
> w32api change was introduced last summer, this is the only
> piece of code I am aware of that was broken by the new
> headers, and of course the purpose of this code is to
Um, going out on a limb here, but those headers are used internally as "cygwin"
apps are most likely to now know about those headers.
> circumvent the Cygwin API (and by extension, Cygwin project goals).
>
> So, perhaps a better path forward is to disable / remove the
> above code by default. (Those wanting a native Win32 git
> should just use the native
> Win32 git).
Or a make option...
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-07 5:37 ` Jason Pyeron
@ 2013-01-07 7:29 ` Junio C Hamano
2013-01-07 9:10 ` Pyeron, Jason J CTR (US)
2013-01-08 3:12 ` Mark Levedahl
0 siblings, 2 replies; 45+ messages in thread
From: Junio C Hamano @ 2013-01-07 7:29 UTC (permalink / raw)
To: Jason Pyeron
Cc: Mark Levedahl, git, Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, Eric Blake
"Jason Pyeron" <jpyeron@pdinc.us> writes:
[administrivia: please never cull CC list when you respond to a
message on this list without a good reason]
>> circumvent the Cygwin API (and by extension, Cygwin project goals).
>>
>> So, perhaps a better path forward is to disable / remove the
>> above code by default. (Those wanting a native Win32 git
>> should just use the native
>> Win32 git).
>
> Or a make option...
It already is a runtime option, isn't it?
I do not have much stake in this personally, but IIRC, the (l)stat
workaround was back then found to make Cygwin version from "unusably
slow" to "slow but torelable", as our POSIX-y codebase assumes that
lstat is fairly efficient, which Cygwin cannot satisify because it
has call many win32 calls to collect bits that we do not even look
at, in order to give faithful emulation. It does place extra
maintenance burden (e.g. conditional compilation depending on the
header file the particular version of Cygwin installation the user
has at hand) on us, but as long as it works, the ugly hack is fairly
isolated and I do not see a reason to unconditionally rip it out,
especially if the reasoning behind such move is on "All programs
that run in Cygwin environment has to be POSIX only and must not use
Win32 API directly, even in a controlled way."
It is a completely different matter if the direct win32 calls we
make, bypassing (l)stat emulation, somehow change the internal state
of win32 resources Cygwin controls and violates the invariants
Cygwin API implemenation expects, breaking later calls to it. I
do not know that is the case here, but I doubt it.
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-07 7:29 ` Junio C Hamano
@ 2013-01-07 9:10 ` Pyeron, Jason J CTR (US)
2013-01-08 3:12 ` Mark Levedahl
1 sibling, 0 replies; 45+ messages in thread
From: Pyeron, Jason J CTR (US) @ 2013-01-07 9:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mark Levedahl, git@vger.kernel.org, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
> -----Original Message-----
> From: Junio C Hamano
> Sent: Monday, January 07, 2013 2:29 AM
>
> Jason Pyeron writes:
>
> [administrivia: please never cull CC list when you respond to a
> message on this list without a good reason]
Apologies, I just have 4 copies of every message and was trying to save other that pain.
>
> >> circumvent the Cygwin API (and by extension, Cygwin project goals).
> >>
> >> So, perhaps a better path forward is to disable / remove the
> >> above code by default. (Those wanting a native Win32 git
> >> should just use the native
> >> Win32 git).
> >
> > Or a make option...
>
> It already is a runtime option, isn't it?
>
> I do not have much stake in this personally, but IIRC, the (l)stat
> workaround was back then found to make Cygwin version from "unusably
> slow" to "slow but torelable", as our POSIX-y codebase assumes that
> lstat is fairly efficient, which Cygwin cannot satisify because it
Is there already a set of test cases I can run to validate that this is still true?
> has call many win32 calls to collect bits that we do not even look
> at, in order to give faithful emulation. It does place extra
> maintenance burden (e.g. conditional compilation depending on the
> header file the particular version of Cygwin installation the user
> has at hand) on us, but as long as it works, the ugly hack is fairly
There seems to be only 2 valid use cases here, with regards to cygwin.
1. Do it the normal posix way, and don’t hack it up.
2. For speed reasons, merge in native windows/non-posix functions.
I would not care about the user's cygwin version because the cygwin supporters won't either. In both cases assume the latest cygwin libraries. If there is a specific user with a use case for an older version of cygwin libraries then we can cross that bridge when (if) we arrive at it.
> isolated and I do not see a reason to unconditionally rip it out,
> especially if the reasoning behind such move is on "All programs
> that run in Cygwin environment has to be POSIX only and must not use
> Win32 API directly, even in a controlled way."
I presently do not care if it stays or goes. But if someone were to bring this to the cygwin mailing list it would be a headache to deal with the "hacked" way. They would likely be more receptive to increasing the efficiency of the lstat than other approaches.
>
> It is a completely different matter if the direct win32 calls we
> make, bypassing (l)stat emulation, somehow change the internal state
> of win32 resources Cygwin controls and violates the invariants
> Cygwin API implemenation expects, breaking later calls to it. I
> do not know that is the case here, but I doubt it.
I agree, it is not going to break anything here. Those libraries are just a way of presenting the Windows API without using Microsoft files and making it easier to wrap the POSIX apis to it.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-07 7:29 ` Junio C Hamano
2013-01-07 9:10 ` Pyeron, Jason J CTR (US)
@ 2013-01-08 3:12 ` Mark Levedahl
2013-01-11 20:08 ` Alex Riesen
1 sibling, 1 reply; 45+ messages in thread
From: Mark Levedahl @ 2013-01-08 3:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jason Pyeron, git, Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Eric Blake
On 01/07/2013 02:29 AM, Junio C Hamano wrote:
>
> I do not have much stake in this personally, but IIRC, the (l)stat
> workaround was back then found to make Cygwin version from "unusably
> slow" to "slow but torelable", as our POSIX-y codebase assumes that
> lstat is fairly efficient, which Cygwin cannot satisify because it
> has call many win32 calls to collect bits that we do not even look
> at, in order to give faithful emulation. It does place extra
> maintenance burden
The maintenance burden is the only issue here, and I just wanted to
point out the origin. I never enable that run-time option, the small
gain in speed cannot compensate the loss of cross-platform operations
for my uses. Actually, my git usage is mostly on Linux, but it seems 99%
of my maintenance time is on the cygwin side that I almost never use. Sigh.
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-08 3:12 ` Mark Levedahl
@ 2013-01-11 20:08 ` Alex Riesen
2013-01-11 20:17 ` Alex Riesen
0 siblings, 1 reply; 45+ messages in thread
From: Alex Riesen @ 2013-01-11 20:08 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
This short discussion on GitHub (file git-compat-util.h) might be relevant:
https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
The change suggested there (to remove an inclusion of windows.h in
git-compat-util.h) might simplify the solution a little. Might even
remove the need for auto-configuration in Makefile (worked for me).
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-11 20:08 ` Alex Riesen
@ 2013-01-11 20:17 ` Alex Riesen
2013-01-13 18:58 ` Mark Levedahl
0 siblings, 1 reply; 45+ messages in thread
From: Alex Riesen @ 2013-01-11 20:17 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>
> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
>
> The change suggested there (to remove an inclusion of windows.h in
> git-compat-util.h) might simplify the solution a little. Might even
> remove the need for auto-configuration in Makefile (worked for me).
Just to be clear, the change is this:
diff --git a/git-compat-util.h b/git-compat-util.h
index 4a1979f..780a919 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,12 +85,6 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
-#include <winsock2.h>
-#include <windows.h>
-#endif
-
#include <unistd.h>
#include <stdio.h>
#include <sys/stat.h>
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-11 20:17 ` Alex Riesen
@ 2013-01-13 18:58 ` Mark Levedahl
2013-01-15 18:47 ` Ramsay Jones
0 siblings, 1 reply; 45+ messages in thread
From: Mark Levedahl @ 2013-01-13 18:58 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
On 01/11/2013 03:17 PM, Alex Riesen wrote:
> On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>>
>> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
>>
>> The change suggested there (to remove an inclusion of windows.h in
>> git-compat-util.h) might simplify the solution a little. Might even
>> remove the need for auto-configuration in Makefile (worked for me).
> Just to be clear, the change is this:
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 4a1979f..780a919 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -85,12 +85,6 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> -#include <winsock2.h>
> -#include <windows.h>
> -#endif
> -
> #include <unistd.h>
> #include <stdio.h>
> #include <sys/stat.h>
>
That change alone seems fine, no apparent change building on current
cygwin. However, with that change the build still fails if
CYGWIN_V15_WIN32API is defined, so unless someone can show the
compilation works on cygwin1.5 WITHOUT defining CYGWIN_V15_WIN32API this
change does not help. I do not have an older installation available, so
cannot test. Frankly, assuming you can compile with that macro defined,
I would suggest leaving well enough alone - an unsupported configuration
is unsupported :^)
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-13 18:58 ` Mark Levedahl
@ 2013-01-15 18:47 ` Ramsay Jones
2013-01-20 10:10 ` Jonathan Nieder
0 siblings, 1 reply; 45+ messages in thread
From: Ramsay Jones @ 2013-01-15 18:47 UTC (permalink / raw)
To: Mark Levedahl
Cc: Alex Riesen, Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
Mark Levedahl wrote:
> On 01/11/2013 03:17 PM, Alex Riesen wrote:
>> On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
>>> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>>>
>>> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
>>>
>>> The change suggested there (to remove an inclusion of windows.h in
>>> git-compat-util.h) might simplify the solution a little. Might even
>>> remove the need for auto-configuration in Makefile (worked for me).
>> Just to be clear, the change is this:
>>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index 4a1979f..780a919 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -85,12 +85,6 @@
>> #define _NETBSD_SOURCE 1
>> #define _SGI_SOURCE 1
>>
>> -#ifdef WIN32 /* Both MinGW and MSVC */
>> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
>> -#include <winsock2.h>
>> -#include <windows.h>
>> -#endif
>> -
>> #include <unistd.h>
>> #include <stdio.h>
>> #include <sys/stat.h>
>>
> That change alone seems fine, no apparent change building on current
> cygwin. However, with that change the build still fails if
> CYGWIN_V15_WIN32API is defined, so unless someone can show the
> compilation works on cygwin1.5 WITHOUT defining CYGWIN_V15_WIN32API this
> change does not help. I do not have an older installation available, so
> cannot test. Frankly, assuming you can compile with that macro defined,
> I would suggest leaving well enough alone - an unsupported configuration
> is unsupported :^)
I haven't been following this thread too closely, so I may have misunderstood
what you would like to test but, since I use cygwin 1.5, I tried the patch
given below.
I only had time to compile test this patch (ie I have *not* run any of the
tests - it takes over 3 hours for me), but it seems to work to that extent.
(I also tried a few simple commands: status, diff, branch; seems to work OK.)
If you would like me to test something else, just let me know.
HTH
ATB,
Ramsay Jones
-- >8 --
diff --git a/Makefile b/Makefile
index 1b30d7b..1c84f68 100644
--- a/Makefile
+++ b/Makefile
@@ -281,10 +281,6 @@ all::
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
#
-# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not
-# using the current w32api packages. The recommended approach, however,
-# is to update your installation if compilation errors occur.
-#
# Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
# user.
#
@@ -1402,9 +1398,6 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
-ifdef CYGWIN_V15_WIN32API
- COMPAT_CFLAGS += -DCYGWIN_V15_WIN32API
-endif
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -Icompat/nedmalloc
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 5428858..0a9aa6d 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -1,13 +1,8 @@
#define WIN32_LEAN_AND_MEAN
-#ifdef CYGWIN_V15_WIN32API
-#include "../git-compat-util.h"
-#include "win32.h"
-#else
#include <sys/stat.h>
#include <sys/errno.h>
#include "win32.h"
#include "../git-compat-util.h"
-#endif
#include "../cache.h" /* to read configuration */
static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..5e493c9 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -158,7 +158,6 @@ ifeq ($(uname_O),Cygwin)
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
OLD_ICONV = UnfortunatelyYes
- CYGWIN_V15_WIN32API = YesPlease
endif
NO_THREAD_SAFE_PREAD = YesPlease
NEEDS_LIBICONV = YesPlease
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b74..3186e55 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,12 +85,6 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
-#include <winsock2.h>
-#include <windows.h>
-#endif
-
#include <unistd.h>
#include <stdio.h>
#include <sys/stat.h>
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-15 18:47 ` Ramsay Jones
@ 2013-01-20 10:10 ` Jonathan Nieder
2013-01-20 10:48 ` Torsten Bögershausen
2013-01-22 18:31 ` Ramsay Jones
0 siblings, 2 replies; 45+ messages in thread
From: Jonathan Nieder @ 2013-01-20 10:10 UTC (permalink / raw)
To: Ramsay Jones
Cc: Mark Levedahl, Alex Riesen, Junio C Hamano, Jason Pyeron, git,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
Ramsay Jones wrote:
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -85,12 +85,6 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> -#include <winsock2.h>
> -#include <windows.h>
> -#endif
So, do I understand correctly that the above conditional should be
something like
#if defined(WIN32) && !defined(__CYGWIN__)
to allow dropping the CYGWIN_V15_WIN32API setting?
"defined(WIN32)" is used throughout git to mean "win32 and not
cygwin", so if I understand correctly we would either need to do
#if defined(WIN32) && defined(__CYGWIN__)
# undef WIN32
#endif
or define a new GIT_WIN32 (name is just a placeholder) macro to use
consistently in its stead.
Thanks for investigating.
Jonathan
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-20 10:10 ` Jonathan Nieder
@ 2013-01-20 10:48 ` Torsten Bögershausen
2013-01-20 11:06 ` Jonathan Nieder
2013-01-22 18:31 ` Ramsay Jones
1 sibling, 1 reply; 45+ messages in thread
From: Torsten Bögershausen @ 2013-01-20 10:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramsay Jones, Mark Levedahl, Alex Riesen, Junio C Hamano,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith, Eric Blake, msysGit
On 20.01.13 11:10, Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -85,12 +85,6 @@
>> #define _NETBSD_SOURCE 1
>> #define _SGI_SOURCE 1
>>
>> -#ifdef WIN32 /* Both MinGW and MSVC */
>> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
>> -#include <winsock2.h>
>> -#include <windows.h>
>> -#endif
>
> So, do I understand correctly that the above conditional should be
> something like
>
> #if defined(WIN32) && !defined(__CYGWIN__)
>
> to allow dropping the CYGWIN_V15_WIN32API setting?
>
> "defined(WIN32)" is used throughout git to mean "win32 and not
> cygwin", so if I understand correctly we would either need to do
>
> #if defined(WIN32) && defined(__CYGWIN__)
> # undef WIN32
> #endif
>
> or define a new GIT_WIN32 (name is just a placeholder) macro to use
> consistently in its stead.
>
> Thanks for investigating.
> Jonathan
I wonder, if if we can go one step further:
Replace
#ifdef WIN32 /* Both MinGW and MSVC */
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
#endif
with
#if defined(_MSC_VER)
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
#endif
Any thougths from msysGit ?
/Torsten
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-20 10:48 ` Torsten Bögershausen
@ 2013-01-20 11:06 ` Jonathan Nieder
2013-01-21 5:20 ` [msysGit] " Torsten Bögershausen
0 siblings, 1 reply; 45+ messages in thread
From: Jonathan Nieder @ 2013-01-20 11:06 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Ramsay Jones, Mark Levedahl, Alex Riesen, Junio C Hamano,
Jason Pyeron, git, Stephen & Linda Smith, Eric Blake, msysGit
Torsten Bögershausen wrote:
> I wonder, if if we can go one step further:
>
> Replace
> #ifdef WIN32 /* Both MinGW and MSVC */
[...]
> with
> #if defined(_MSC_VER)
I thought Git for Windows was built using mingw, which doesn't define
_MSC_VER?
Puzzled,
Jonathan
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [msysGit] Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-20 11:06 ` Jonathan Nieder
@ 2013-01-21 5:20 ` Torsten Bögershausen
2013-01-22 18:38 ` Ramsay Jones
0 siblings, 1 reply; 45+ messages in thread
From: Torsten Bögershausen @ 2013-01-21 5:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Torsten Bögershausen, Ramsay Jones, Mark Levedahl,
Alex Riesen, Junio C Hamano, Jason Pyeron, git,
Stephen & Linda Smith, Eric Blake, msysGit
On 20.01.13 12:06, Jonathan Nieder wrote:
> Torsten Bögershausen wrote:
>
>> I wonder, if if we can go one step further:
>>
>> Replace
>> #ifdef WIN32 /* Both MinGW and MSVC */
> [...]
>> with
>> #if defined(_MSC_VER)
>
> I thought Git for Windows was built using mingw, which doesn't define
> _MSC_VER?
>
> Puzzled,
> Jonathan
>
Yes,
After removing these lines in the git-compat-util.h of msysgit
v1.8.1 it still compiled.
So I start to speculate if the comment is still valid for mingw,
or if that was true in the old days and not now any more.
More investigation is needed, sorry for confusion.
/Torsten
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-20 10:10 ` Jonathan Nieder
2013-01-20 10:48 ` Torsten Bögershausen
@ 2013-01-22 18:31 ` Ramsay Jones
2013-01-25 23:58 ` Mark Levedahl
1 sibling, 1 reply; 45+ messages in thread
From: Ramsay Jones @ 2013-01-22 18:31 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Mark Levedahl, Alex Riesen, Junio C Hamano, Jason Pyeron, git,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -85,12 +85,6 @@
>> #define _NETBSD_SOURCE 1
>> #define _SGI_SOURCE 1
>>
>> -#ifdef WIN32 /* Both MinGW and MSVC */
>> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
>> -#include <winsock2.h>
>> -#include <windows.h>
>> -#endif
>
> So, do I understand correctly that the above conditional should be
> something like
>
> #if defined(WIN32) && !defined(__CYGWIN__)
>
> to allow dropping the CYGWIN_V15_WIN32API setting?
Yes, replacing the git-compat-util.h hunk above with:
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b74..a38ae8d 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,7 +85,7 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
+#if defined(WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
will also compile on cygwin 1.5.x
> "defined(WIN32)" is used throughout git to mean "win32 and not
> cygwin", so if I understand correctly we would either need to do
Hmm ... I remember being *very* nervous of commit 435bdf8c ("Make
usage of windows.h lean and mean", 16-09-2009) exactly because it
makes the code (on cygwin) much more fragile with respect to header
include order. ;-)
As I have mentioned here before, the claim that "WIN32 is not defined
on cygwin" is simply nonsense - it depends on if/when certain header
files are included. For example, *as soon as* you include <windows.h>
(and, I suspect, many other win32 headers) then "defined(WIN32)"
is true.
Note that commit 380a4d92 ("Update cygwin.c for new mingw-64 win32 api
headers", 11-11-2012) swaps the include order for the win32.h and
git-compat-util.h header files. [I don't know the details, Mark didn't
elaborate, but it is clearly an include order problem on cygwin 1.7.x :-D ]
This causes compilation errors on cygwin 1.5.x, exactly because win32.h
includes <windows.h>, which defines WIN32, which then leads to
git-compat-util.h including <winsock2.h>.
> #if defined(WIN32) && defined(__CYGWIN__)
> # undef WIN32
> #endif
Hmm, except when you want it defined on cygwin, of course ... ;-)
> Thanks for investigating.
No problem.
I've included the updated patch below, just for completeness.
HTH
ATB,
Ramsay Jones
-- >8 --
Subject: [PATCH] cygwin: Remove the CYGWIN_V15_WIN32API config
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Makefile | 7 -------
compat/cygwin.c | 5 -----
config.mak.uname | 1 -
git-compat-util.h | 2 +-
4 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 1b30d7b..1c84f68 100644
--- a/Makefile
+++ b/Makefile
@@ -281,10 +281,6 @@ all::
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
#
-# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not
-# using the current w32api packages. The recommended approach, however,
-# is to update your installation if compilation errors occur.
-#
# Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the
# user.
#
@@ -1402,9 +1398,6 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
-ifdef CYGWIN_V15_WIN32API
- COMPAT_CFLAGS += -DCYGWIN_V15_WIN32API
-endif
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -Icompat/nedmalloc
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 5428858..0a9aa6d 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -1,13 +1,8 @@
#define WIN32_LEAN_AND_MEAN
-#ifdef CYGWIN_V15_WIN32API
-#include "../git-compat-util.h"
-#include "win32.h"
-#else
#include <sys/stat.h>
#include <sys/errno.h>
#include "win32.h"
#include "../git-compat-util.h"
-#endif
#include "../cache.h" /* to read configuration */
static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..5e493c9 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -158,7 +158,6 @@ ifeq ($(uname_O),Cygwin)
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
OLD_ICONV = UnfortunatelyYes
- CYGWIN_V15_WIN32API = YesPlease
endif
NO_THREAD_SAFE_PREAD = YesPlease
NEEDS_LIBICONV = YesPlease
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b74..a38ae8d 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,7 +85,7 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
+#if defined(WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
--
1.8.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [msysGit] Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-21 5:20 ` [msysGit] " Torsten Bögershausen
@ 2013-01-22 18:38 ` Ramsay Jones
0 siblings, 0 replies; 45+ messages in thread
From: Ramsay Jones @ 2013-01-22 18:38 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Jonathan Nieder, Mark Levedahl, Alex Riesen, Junio C Hamano,
Jason Pyeron, git, Stephen & Linda Smith, Eric Blake, msysGit
Torsten Bögershausen wrote:
> On 20.01.13 12:06, Jonathan Nieder wrote:
>> Torsten Bögershausen wrote:
>>
>>> I wonder, if if we can go one step further:
>>>
>>> Replace
>>> #ifdef WIN32 /* Both MinGW and MSVC */
>> [...]
>>> with
>>> #if defined(_MSC_VER)
>>
>> I thought Git for Windows was built using mingw, which doesn't define
>> _MSC_VER?
>>
>> Puzzled,
>> Jonathan
>>
> Yes,
> After removing these lines in the git-compat-util.h of msysgit
> v1.8.1 it still compiled.
> So I start to speculate if the comment is still valid for mingw,
> or if that was true in the old days and not now any more.
>
> More investigation is needed, sorry for confusion.
Yes, I compiled the last patch on MinGW before I sent it to the list.
I didn't bother with MSVC, since that build is already broken.
I have a patch which fixed the MSVC build, but it already needs to
be updated, since current master fails to build on MSVC.
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-22 18:31 ` Ramsay Jones
@ 2013-01-25 23:58 ` Mark Levedahl
2013-01-26 0:11 ` Junio C Hamano
0 siblings, 1 reply; 45+ messages in thread
From: Mark Levedahl @ 2013-01-25 23:58 UTC (permalink / raw)
To: Ramsay Jones
Cc: Jonathan Nieder, Alex Riesen, Junio C Hamano, Jason Pyeron, git,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
On 01/22/2013 01:31 PM, Ramsay Jones wrote:
> include order. ;-) As I have mentioned here before, the claim that
> "WIN32 is not defined on cygwin" is simply nonsense - it depends on
> if/when certain header files are included. For example, *as soon as*
> you include <windows.h> (and, I suspect, many other win32 headers)
> then "defined(WIN32)" is true. Note that commit 380a4d92 ("Update
> cygwin.c for new mingw-64 win32 api headers", 11-11-2012) swaps the
> include order for the win32.h and git-compat-util.h header files. [I
> don't know the details, Mark didn't elaborate, but it is clearly an
> include order problem on cygwin 1.7.x :-D ] This causes compilation
> errors on cygwin 1.5.x, exactly because win32.h includes <windows.h>,
> which defines WIN32, which then leads to git-compat-util.h including
> <winsock2.h>.
>> #if defined(WIN32) && defined(__CYGWIN__)
>> # undef WIN32
>> #endif
>
Cygwin and Windows should be treated as completely separate platforms:
if __CYGWIN__ is defined, do one thing, if not, go ahead and check
WIN32, but the WIN32 macro should never be tested once we know the
platform is CYGWIN - these really are different platforms (if you are
unsure of this, consider that Cygwin includes a cross-compiler to target
native Win32 as the Cygwin maintainers recognized the platforms are
different).
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-25 23:58 ` Mark Levedahl
@ 2013-01-26 0:11 ` Junio C Hamano
2013-01-26 0:34 ` Eric Blake
0 siblings, 1 reply; 45+ messages in thread
From: Junio C Hamano @ 2013-01-26 0:11 UTC (permalink / raw)
To: Mark Levedahl
Cc: Ramsay Jones, Jonathan Nieder, Alex Riesen, Jason Pyeron, git,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
Mark Levedahl <mlevedahl@gmail.com> writes:
> Cygwin and Windows should be treated as completely separate platforms:
> if __CYGWIN__ is defined, do one thing, if not, go ahead and check
> WIN32, but the WIN32 macro should never be tested once we know the
> platform is CYGWIN - these really are different platforms (if you are
> unsure of this, consider that Cygwin includes a cross-compiler to
> target native Win32 as the Cygwin maintainers recognized the platforms
> are different).
Not disagreeing with your conclusion (they should be treated as
different), why does it define WIN32 in the first place?
Perhaps we would want
#ifdef __CYGWIN__
#undef WIN32
#endif
very early in some include file before nothing else is included?
Just being curious.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
2013-01-26 0:11 ` Junio C Hamano
@ 2013-01-26 0:34 ` Eric Blake
2013-01-26 1:03 ` [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS Jonathan Nieder
0 siblings, 1 reply; 45+ messages in thread
From: Eric Blake @ 2013-01-26 0:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mark Levedahl, Ramsay Jones, Jonathan Nieder, Alex Riesen,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
On 01/25/2013 05:11 PM, Junio C Hamano wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>> Cygwin and Windows should be treated as completely separate platforms:
>> if __CYGWIN__ is defined, do one thing, if not, go ahead and check
>> WIN32, but the WIN32 macro should never be tested once we know the
>> platform is CYGWIN - these really are different platforms (if you are
>> unsure of this, consider that Cygwin includes a cross-compiler to
>> target native Win32 as the Cygwin maintainers recognized the platforms
>> are different).
>
> Not disagreeing with your conclusion (they should be treated as
> different), why does it define WIN32 in the first place?
>
> Perhaps we would want
>
> #ifdef __CYGWIN__
> #undef WIN32
> #endif
Wouldn't work. Cygwin gcc does NOT define WIN32; rather, the inclusion
of a Windows system header (generally discouraged, but sometimes a
necessary evil) might cause WIN32 to be defined for all subsequent headers.
Which is why other projects, like gnulib, have
# if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
all over the place.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-01-26 0:34 ` Eric Blake
@ 2013-01-26 1:03 ` Jonathan Nieder
2013-01-26 14:11 ` Mark Levedahl
` (2 more replies)
0 siblings, 3 replies; 45+ messages in thread
From: Jonathan Nieder @ 2013-01-26 1:03 UTC (permalink / raw)
To: Eric Blake
Cc: Junio C Hamano, Mark Levedahl, Ramsay Jones, Alex Riesen,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
Throughout git, it is assumed that the WIN32 preprocessor symbol is
defined on native Windows setups (mingw and msvc) and not on Cygwin.
On Cygwin, most of the time git can pretend this is just another Unix
machine, and Windows-specific magic is generally counterproductive.
Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
defined as follows:
#if defined(WIN32) && !defined(__CYGWIN__)
# define NATIVE_WINDOWS
#endif
After this change, it should be possible to drop the
CYGWIN_V15_WIN32API setting without any negative effect.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Eric Blake wrote:
> Which is why other projects, like gnulib, have
>
> # if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>
> all over the place.
So, how about this?
Completely untested.
abspath.c | 2 +-
compat/terminal.c | 4 ++--
compat/win32.h | 2 +-
diff-no-index.c | 2 +-
git-compat-util.h | 3 ++-
help.c | 2 +-
run-command.c | 10 +++++-----
test-chmtime.c | 2 +-
thread-utils.c | 2 +-
9 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/abspath.c b/abspath.c
index 40cdc462..c7d5458e 100644
--- a/abspath.c
+++ b/abspath.c
@@ -216,7 +216,7 @@ const char *absolute_path(const char *path)
const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
{
static char path[PATH_MAX];
-#ifndef WIN32
+#ifndef WINDOWS_NATIVE
if (!pfx_len || is_absolute_path(arg))
return arg;
memcpy(path, pfx, pfx_len);
diff --git a/compat/terminal.c b/compat/terminal.c
index 9b5e3d1b..136e4a74 100644
--- a/compat/terminal.c
+++ b/compat/terminal.c
@@ -3,7 +3,7 @@
#include "sigchain.h"
#include "strbuf.h"
-#if defined(HAVE_DEV_TTY) || defined(WIN32)
+#if defined(HAVE_DEV_TTY) || defined(WINDOWS_NATIVE)
static void restore_term(void);
@@ -53,7 +53,7 @@ error:
return -1;
}
-#elif defined(WIN32)
+#elif defined(WINDOWS_NATIVE)
#define INPUT_PATH "CONIN$"
#define OUTPUT_PATH "CONOUT$"
diff --git a/compat/win32.h b/compat/win32.h
index 8ce91048..31dd30f7 100644
--- a/compat/win32.h
+++ b/compat/win32.h
@@ -2,7 +2,7 @@
#define WIN32_H
/* common Win32 functions for MinGW and Cygwin */
-#ifndef WIN32 /* Not defined by Cygwin */
+#ifndef WINDOWS_NATIVE /* Not defined for Cygwin */
#include <windows.h>
#endif
diff --git a/diff-no-index.c b/diff-no-index.c
index 74da6593..a0bc9c50 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -45,7 +45,7 @@ static int get_mode(const char *path, int *mode)
if (!path || !strcmp(path, "/dev/null"))
*mode = 0;
-#ifdef _WIN32
+#ifdef WINDOWS_NATIVE
else if (!strcasecmp(path, "nul"))
*mode = 0;
#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b745..ebbdff53 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,10 +85,11 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
+#if defined(WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
+#define WINDOWS_NATIVE
#endif
#include <unistd.h>
diff --git a/help.c b/help.c
index 2a42ec6d..cc1e63f7 100644
--- a/help.c
+++ b/help.c
@@ -106,7 +106,7 @@ static int is_executable(const char *name)
!S_ISREG(st.st_mode))
return 0;
-#if defined(WIN32) || defined(__CYGWIN__)
+#if defined(WINDOWS_NATIVE) || defined(__CYGWIN__)
#if defined(__CYGWIN__)
if ((st.st_mode & S_IXUSR) == 0)
#endif
diff --git a/run-command.c b/run-command.c
index 04712191..04ac6181 100644
--- a/run-command.c
+++ b/run-command.c
@@ -72,7 +72,7 @@ static inline void close_pair(int fd[2])
close(fd[1]);
}
-#ifndef WIN32
+#ifndef WINDOWS_NATIVE
static inline void dup_devnull(int to)
{
int fd = open("/dev/null", O_RDWR);
@@ -159,7 +159,7 @@ static const char **prepare_shell_cmd(const char **argv)
die("BUG: shell command is empty");
if (strcspn(argv[0], "|&;<>()$`\\\"' \t\n*?[#~=%") != strlen(argv[0])) {
-#ifndef WIN32
+#ifndef WINDOWS_NATIVE
nargv[nargc++] = SHELL_PATH;
#else
nargv[nargc++] = "sh";
@@ -182,7 +182,7 @@ static const char **prepare_shell_cmd(const char **argv)
return nargv;
}
-#ifndef WIN32
+#ifndef WINDOWS_NATIVE
static int execv_shell_cmd(const char **argv)
{
const char **nargv = prepare_shell_cmd(argv);
@@ -193,7 +193,7 @@ static int execv_shell_cmd(const char **argv)
}
#endif
-#ifndef WIN32
+#ifndef WINDOWS_NATIVE
static int child_err = 2;
static int child_notifier = -1;
@@ -330,7 +330,7 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
fflush(NULL);
-#ifndef WIN32
+#ifndef WINDOWS_NATIVE
{
int notify_pipe[2];
if (pipe(notify_pipe))
diff --git a/test-chmtime.c b/test-chmtime.c
index 92713d16..803b6055 100644
--- a/test-chmtime.c
+++ b/test-chmtime.c
@@ -87,7 +87,7 @@ int main(int argc, const char *argv[])
return -1;
}
-#ifdef WIN32
+#ifdef WINDOWS_NATIVE
if (!(sb.st_mode & S_IWUSR) &&
chmod(argv[i], sb.st_mode | S_IWUSR)) {
fprintf(stderr, "Could not make user-writable %s: %s",
diff --git a/thread-utils.c b/thread-utils.c
index 7f4b76a9..4c4cf2fa 100644
--- a/thread-utils.c
+++ b/thread-utils.c
@@ -24,7 +24,7 @@ int online_cpus(void)
long ncpus;
#endif
-#ifdef _WIN32
+#ifdef WINDOWS_NATIVE
SYSTEM_INFO info;
GetSystemInfo(&info);
--
1.8.1.1
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-01-26 1:03 ` [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS Jonathan Nieder
@ 2013-01-26 14:11 ` Mark Levedahl
2013-01-26 17:21 ` Torsten Bögershausen
2013-01-28 18:29 ` Ramsay Jones
2 siblings, 0 replies; 45+ messages in thread
From: Mark Levedahl @ 2013-01-26 14:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Eric Blake, Junio C Hamano, Ramsay Jones, Alex Riesen,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
On 01/25/2013 08:03 PM, Jonathan Nieder wrote:
> diff --git a/abspath.c b/abspath.c
> index 40cdc462..c7d5458e 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -216,7 +216,7 @@ const char *absolute_path(const char *path)
> const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
> {
> static char path[PATH_MAX];
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> if (!pfx_len || is_absolute_path(arg))
> return arg;
> memcpy(path, pfx, pfx_len);
> diff --git a/compat/terminal.c b/compat/terminal.c
> index 9b5e3d1b..136e4a74 100644
Maybe WINDOWS_NATIVE should be defined in config.mak.uname?
Otherwise, I tested the patch and it does build / run on Cygwin, but I
cannot run a test suite until next week. I am concerned about subtle
changes due to the various WIN32 tests that were not guarded by
__CYGWIN__ before, haven't stared at the code enough to see if there
could be an issue.
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-01-26 1:03 ` [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS Jonathan Nieder
2013-01-26 14:11 ` Mark Levedahl
@ 2013-01-26 17:21 ` Torsten Bögershausen
2013-01-28 18:29 ` Ramsay Jones
2 siblings, 0 replies; 45+ messages in thread
From: Torsten Bögershausen @ 2013-01-26 17:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Eric Blake, Junio C Hamano, Mark Levedahl, Ramsay Jones,
Alex Riesen, Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
On 26.01.13 02:03, Jonathan Nieder wrote:
> Throughout git, it is assumed that the WIN32 preprocessor symbol is
> defined on native Windows setups (mingw and msvc) and not on Cygwin.
> On Cygwin, most of the time git can pretend this is just another Unix
> machine, and Windows-specific magic is generally counterproductive.
>
> Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
> Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
> defined as follows:
>
> #if defined(WIN32) && !defined(__CYGWIN__)
> # define NATIVE_WINDOWS
> #endif
>
> After this change, it should be possible to drop the
> CYGWIN_V15_WIN32API setting without any negative effect.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Eric Blake wrote:
>
>> Which is why other projects, like gnulib, have
>>
>> # if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
>>
>> all over the place.
> So, how about this?
>
> Completely untested.
>
> abspath.c | 2 +-
> compat/terminal.c | 4 ++--
> compat/win32.h | 2 +-
> diff-no-index.c | 2 +-
> git-compat-util.h | 3 ++-
> help.c | 2 +-
> run-command.c | 10 +++++-----
> test-chmtime.c | 2 +-
> thread-utils.c | 2 +-
> 9 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/abspath.c b/abspath.c
> index 40cdc462..c7d5458e 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -216,7 +216,7 @@ const char *absolute_path(const char *path)
> const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
> {
> static char path[PATH_MAX];
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> if (!pfx_len || is_absolute_path(arg))
> return arg;
> memcpy(path, pfx, pfx_len);
> diff --git a/compat/terminal.c b/compat/terminal.c
> index 9b5e3d1b..136e4a74 100644
> --- a/compat/terminal.c
> +++ b/compat/terminal.c
> @@ -3,7 +3,7 @@
> #include "sigchain.h"
> #include "strbuf.h"
>
> -#if defined(HAVE_DEV_TTY) || defined(WIN32)
> +#if defined(HAVE_DEV_TTY) || defined(WINDOWS_NATIVE)
>
> static void restore_term(void);
>
> @@ -53,7 +53,7 @@ error:
> return -1;
> }
>
> -#elif defined(WIN32)
> +#elif defined(WINDOWS_NATIVE)
>
> #define INPUT_PATH "CONIN$"
> #define OUTPUT_PATH "CONOUT$"
> diff --git a/compat/win32.h b/compat/win32.h
> index 8ce91048..31dd30f7 100644
> --- a/compat/win32.h
> +++ b/compat/win32.h
> @@ -2,7 +2,7 @@
> #define WIN32_H
>
> /* common Win32 functions for MinGW and Cygwin */
> -#ifndef WIN32 /* Not defined by Cygwin */
> +#ifndef WINDOWS_NATIVE /* Not defined for Cygwin */
> #include <windows.h>
> #endif
>
> diff --git a/diff-no-index.c b/diff-no-index.c
> index 74da6593..a0bc9c50 100644
> --- a/diff-no-index.c
> +++ b/diff-no-index.c
> @@ -45,7 +45,7 @@ static int get_mode(const char *path, int *mode)
>
> if (!path || !strcmp(path, "/dev/null"))
> *mode = 0;
> -#ifdef _WIN32
> +#ifdef WINDOWS_NATIVE
> else if (!strcasecmp(path, "nul"))
> *mode = 0;
> #endif
> diff --git a/git-compat-util.h b/git-compat-util.h
> index e5a4b745..ebbdff53 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -85,10 +85,11 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> +#if defined(WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */
> #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> #include <winsock2.h>
> #include <windows.h>
> +#define WINDOWS_NATIVE
> #endif
>
> #include <unistd.h>
> diff --git a/help.c b/help.c
> index 2a42ec6d..cc1e63f7 100644
> --- a/help.c
> +++ b/help.c
> @@ -106,7 +106,7 @@ static int is_executable(const char *name)
> !S_ISREG(st.st_mode))
> return 0;
>
> -#if defined(WIN32) || defined(__CYGWIN__)
> +#if defined(WINDOWS_NATIVE) || defined(__CYGWIN__)
> #if defined(__CYGWIN__)
> if ((st.st_mode & S_IXUSR) == 0)
> #endif
> diff --git a/run-command.c b/run-command.c
> index 04712191..04ac6181 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -72,7 +72,7 @@ static inline void close_pair(int fd[2])
> close(fd[1]);
> }
>
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> static inline void dup_devnull(int to)
> {
> int fd = open("/dev/null", O_RDWR);
> @@ -159,7 +159,7 @@ static const char **prepare_shell_cmd(const char **argv)
> die("BUG: shell command is empty");
>
> if (strcspn(argv[0], "|&;<>()$`\\\"' \t\n*?[#~=%") != strlen(argv[0])) {
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> nargv[nargc++] = SHELL_PATH;
> #else
> nargv[nargc++] = "sh";
> @@ -182,7 +182,7 @@ static const char **prepare_shell_cmd(const char **argv)
> return nargv;
> }
>
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> static int execv_shell_cmd(const char **argv)
> {
> const char **nargv = prepare_shell_cmd(argv);
> @@ -193,7 +193,7 @@ static int execv_shell_cmd(const char **argv)
> }
> #endif
>
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> static int child_err = 2;
> static int child_notifier = -1;
>
> @@ -330,7 +330,7 @@ fail_pipe:
> trace_argv_printf(cmd->argv, "trace: run_command:");
> fflush(NULL);
>
> -#ifndef WIN32
> +#ifndef WINDOWS_NATIVE
> {
> int notify_pipe[2];
> if (pipe(notify_pipe))
> diff --git a/test-chmtime.c b/test-chmtime.c
> index 92713d16..803b6055 100644
> --- a/test-chmtime.c
> +++ b/test-chmtime.c
> @@ -87,7 +87,7 @@ int main(int argc, const char *argv[])
> return -1;
> }
>
> -#ifdef WIN32
> +#ifdef WINDOWS_NATIVE
> if (!(sb.st_mode & S_IWUSR) &&
> chmod(argv[i], sb.st_mode | S_IWUSR)) {
> fprintf(stderr, "Could not make user-writable %s: %s",
> diff --git a/thread-utils.c b/thread-utils.c
> index 7f4b76a9..4c4cf2fa 100644
> --- a/thread-utils.c
> +++ b/thread-utils.c
> @@ -24,7 +24,7 @@ int online_cpus(void)
> long ncpus;
> #endif
>
> -#ifdef _WIN32
> +#ifdef WINDOWS_NATIVE
> SYSTEM_INFO info;
> GetSystemInfo(&info);
>
Thanks, that looks good.
I run the test suite under XP, the same test cases are broken as on 1.8.1.1
/Torsten
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-01-26 1:03 ` [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS Jonathan Nieder
2013-01-26 14:11 ` Mark Levedahl
2013-01-26 17:21 ` Torsten Bögershausen
@ 2013-01-28 18:29 ` Ramsay Jones
2013-02-25 6:44 ` Junio C Hamano
2 siblings, 1 reply; 45+ messages in thread
From: Ramsay Jones @ 2013-01-28 18:29 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Eric Blake, Junio C Hamano, Mark Levedahl, Alex Riesen,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
Jonathan Nieder wrote:
> Throughout git, it is assumed that the WIN32 preprocessor symbol is
> defined on native Windows setups (mingw and msvc) and not on Cygwin.
> On Cygwin, most of the time git can pretend this is just another Unix
> machine, and Windows-specific magic is generally counterproductive.
>
> Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
> Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
> defined as follows:
>
> #if defined(WIN32) && !defined(__CYGWIN__)
> # define NATIVE_WINDOWS
> #endif
>
> After this change, it should be possible to drop the
> CYGWIN_V15_WIN32API setting without any negative effect.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
If we go with this approach, could we prefix the symbol name with GIT_
in order to reduce the global namespace pollution?
eg GIT_NATIVE_WINDOWS, or GIT_NATIVE_WIN32 or just GIT_WIN32.
(Yeah, I'm not good at choosing names!)
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-01-28 18:29 ` Ramsay Jones
@ 2013-02-25 6:44 ` Junio C Hamano
2013-02-26 4:08 ` Mark Levedahl
0 siblings, 1 reply; 45+ messages in thread
From: Junio C Hamano @ 2013-02-25 6:44 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Eric Blake, Mark Levedahl, Alex Riesen,
Jason Pyeron, Torsten Bögershausen,
Stephen & Linda Smith, Ramsay Jones
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Jonathan Nieder wrote:
>
>> Throughout git, it is assumed that the WIN32 preprocessor symbol is
>> defined on native Windows setups (mingw and msvc) and not on Cygwin.
>> On Cygwin, most of the time git can pretend this is just another Unix
>> machine, and Windows-specific magic is generally counterproductive.
>>
>> Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
>> Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
>> defined as follows:
>>
>> #if defined(WIN32) && !defined(__CYGWIN__)
>> # define NATIVE_WINDOWS
>> #endif
>>
>> After this change, it should be possible to drop the
>> CYGWIN_V15_WIN32API setting without any negative effect.
>>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>
> If we go with this approach, could we prefix the symbol name with GIT_
> in order to reduce the global namespace pollution?
>
> eg GIT_NATIVE_WINDOWS, or GIT_NATIVE_WIN32 or just GIT_WIN32.
> (Yeah, I'm not good at choosing names!)
I was in "find leftover bits" mode today and found this thread hanging.
Has anything come out of this thread, or there is nothing to improve
in this area?
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-02-25 6:44 ` Junio C Hamano
@ 2013-02-26 4:08 ` Mark Levedahl
2013-02-26 16:40 ` Torsten Bögershausen
0 siblings, 1 reply; 45+ messages in thread
From: Mark Levedahl @ 2013-02-26 4:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Eric Blake, Alex Riesen, Jason Pyeron,
Torsten Bögershausen, Stephen & Linda Smith,
Ramsay Jones
On 02/25/2013 01:44 AM, Junio C Hamano wrote:
> I was in "find leftover bits" mode today and found this thread
> hanging. Has anything come out of this thread, or there is nothing to
> improve in this area?
The patch passed my simple tests (build, run a few commands), but I
didn't get around to a full test. And of course, I am testing on current
Cygwin where git compiles and runs correctly anyway.
Mark
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
2013-02-26 4:08 ` Mark Levedahl
@ 2013-02-26 16:40 ` Torsten Bögershausen
0 siblings, 0 replies; 45+ messages in thread
From: Torsten Bögershausen @ 2013-02-26 16:40 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, git, Jonathan Nieder, Eric Blake, Alex Riesen,
Jason Pyeron, Torsten Bögershausen,
Stephen & Linda Smith, Ramsay Jones
On 26.02.13 05:08, Mark Levedahl wrote:
> On 02/25/2013 01:44 AM, Junio C Hamano wrote:
>> I was in "find leftover bits" mode today and found this thread hanging. Has anything come out of this thread, or there is nothing to improve in this area?
>
> The patch passed my simple tests (build, run a few commands), but I didn't get around to a full test. And of course, I am testing on current Cygwin where git compiles and runs correctly anyway.
>
> Mark
I run the test suite, and there was 1301 failing (and t0070 ?) which have
to do with POSIX permisions.
They are on my TODO stack.
/Torsten
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2013-02-26 16:43 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-06 2:04 Version 1.8.1 does not compile on Cygwin 1.7.14 Stephen & Linda Smith
2013-01-06 3:37 ` Jason Pyeron
2013-01-06 4:22 ` Jason Pyeron
2013-01-06 6:20 ` Stephen & Linda Smith
2013-01-06 6:29 ` Jason Pyeron
2013-01-06 7:23 ` Torsten Bögershausen
2013-01-06 9:32 ` Jonathan Nieder
2013-01-06 9:42 ` Torsten Bögershausen
2013-01-06 9:57 ` Jonathan Nieder
2013-01-06 11:48 ` Mark Levedahl
2013-01-06 12:09 ` Jonathan Nieder
2013-01-06 14:09 ` Stephen & Linda Smith
2013-01-06 19:54 ` Junio C Hamano
2013-01-06 20:51 ` Torsten Bögershausen
2013-01-06 21:34 ` Mark Levedahl
2013-01-06 21:09 ` Mark Levedahl
2013-01-06 21:33 ` Jason Pyeron
2013-01-06 21:35 ` Junio C Hamano
2013-01-06 21:46 ` Jason Pyeron
2013-01-06 22:00 ` Mark Levedahl
2013-01-06 22:16 ` Mark Levedahl
2013-01-07 5:37 ` Jason Pyeron
2013-01-07 7:29 ` Junio C Hamano
2013-01-07 9:10 ` Pyeron, Jason J CTR (US)
2013-01-08 3:12 ` Mark Levedahl
2013-01-11 20:08 ` Alex Riesen
2013-01-11 20:17 ` Alex Riesen
2013-01-13 18:58 ` Mark Levedahl
2013-01-15 18:47 ` Ramsay Jones
2013-01-20 10:10 ` Jonathan Nieder
2013-01-20 10:48 ` Torsten Bögershausen
2013-01-20 11:06 ` Jonathan Nieder
2013-01-21 5:20 ` [msysGit] " Torsten Bögershausen
2013-01-22 18:38 ` Ramsay Jones
2013-01-22 18:31 ` Ramsay Jones
2013-01-25 23:58 ` Mark Levedahl
2013-01-26 0:11 ` Junio C Hamano
2013-01-26 0:34 ` Eric Blake
2013-01-26 1:03 ` [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS Jonathan Nieder
2013-01-26 14:11 ` Mark Levedahl
2013-01-26 17:21 ` Torsten Bögershausen
2013-01-28 18:29 ` Ramsay Jones
2013-02-25 6:44 ` Junio C Hamano
2013-02-26 4:08 ` Mark Levedahl
2013-02-26 16:40 ` Torsten Bögershausen
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).