X-Spam-Check-By: sourceware.org From: "Dave Korn" To: , Subject: Cygwin c++ vs windows or unix socket layer Date: Fri, 26 May 2006 17:58:49 +0100 Message-ID: <00b101c680e5$a8f914c0$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Hi all, I've stumbled across a small problem. As you may know, cygwin attempts to give the user a free choice of using the winsock API, with SOCKETs being handles not fds, and ioctlsocket and closesocket and so on, or using the posix sockets API, and having sockets being fds just like any other file, using the same ioctl and close functions, etc. etc. This doesn't work well in C++ at the moment, because of a clash between headers; winsock defines gethostname to take an int as the second argument, while cygwin's unistd.h defines it as taking an unsigned int. Normally the solution to this would be to only use one or the other kind of socket library and not attempt to mix the two in one program. Unfortunately, if you include any of the C++ i/o stream related headers, that includes c++io.h, which includes gthr.h and hence gthr-default.h; and gthr-default.h unconditionally #includes . (Note that gthr-posix.h could cause the same problem, if you've explicitly requested posix threads by defining _GLIBCXX__PTHREADS). So the upshot is that if you use C++ i/o streams you get unistd.h included and that defines the posix version of gethostname and then you can't include (or use) the winsock stuff instead; i.e. cygwin's c++ compiler does not currently support allowing the choice of socket library. There's no problem in C, because you're not forced to include the gthreads headers to support standard library functions; it's just that the C++ i/o classes need to know about mutex functionality in order to be threadsafe. A patch like this makes it work for me, and I was wondering if anyone else has had this problem and if I should include it in the next release of cygwin gcc when it comes out. According to the svn logs, the reason gthr-default/posix.h needs to include unistd is solely to get the feature test macros; although posix expects them to be available /through/ unistd.h I think we're still ok by having it as a separate subinclude file and that does give us the advantage of being able to pull them in without all the hundreds and thousands of random unrelated stuff that the full unistd.h has. I've Cc'd the gcc list because, although this is primarily a cygwin issue, and an artifact of the way we try to support two clashing environments, a) someone might know some more important reason why gthr-default really does need the unistd function prototypes, or b) others might also feel that implicitly including unistd.h and thus pulling in a bunch of network/socket related symbols into every C++ io stream-related header file is a bit overly namespace-polluting. c) something else, that I haven't thought of :) --- gthr-default.h 2006-05-26 16:59:57.917146100 +0100 +++ gthr-default.h.new 2006-05-26 17:00:26.307771100 +0100 @@ -41,7 +41,11 @@ Software Foundation, 59 Temple Place - S #endif #include +#ifdef __CYGWIN__ +#include +#else #include +#endif typedef pthread_key_t __gthread_key_t; typedef pthread_once_t __gthread_once_t; dk AT rainbow /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin/bits> cheers, DaveK -- Can't think of a witty .sigline today.... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/