From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130512 invoked by alias); 15 Apr 2016 20:54:25 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 130498 invoked by uid 89); 15 Apr 2016 20:54:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=publish X-HELO: mail-vk0-f53.google.com Received: from mail-vk0-f53.google.com (HELO mail-vk0-f53.google.com) (209.85.213.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 15 Apr 2016 20:54:14 +0000 Received: by mail-vk0-f53.google.com with SMTP id t129so161435720vkg.2 for ; Fri, 15 Apr 2016 13:54:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=nY9UT3/NcL4YmqpTmfVjWDwb0lwAGpWls+AAaZ/S2wA=; b=Swk+T8FgHkBOF4H6RKcXpDnRzj7u0WrARcq1Vah/W6hN9xmerDtCDjLZDSaGlgTc3o YuvuHxMFL3LH90Q/iR/EgWotuzBPt6Eo9Z+gg3WjaJCLLEPC1Hloi0By3op/FVMLaSsp nMcg5LcCIxLIcSZRBm5rLM7rGdkstQXWNXDDBXVQXtFJlXAXrX76KO1SryyASy9zfYfS f6MfEnwclPFGlOzb15xMo0rN9jmf44rGl+NQgp+x8BOLiyUrLtsJpT2Kkd+qDbIHWG0X i6cbl+9wjpQ13Vqa2XyFBvZIYLA1JqT50rtlzYp6siPdmNAgSbKOh/mlU3cl37ePWDyA N09Q== X-Gm-Message-State: AOPr4FVjUhquF4nidyninBFBI1Aa76odVXeY2YaEY8BTkQCb+xsUc/BWIn/alASu6SwjE9S/rt5q+utA9Lj10Q== MIME-Version: 1.0 X-Received: by 10.31.167.195 with SMTP id q186mr11479365vke.113.1460753651766; Fri, 15 Apr 2016 13:54:11 -0700 (PDT) Received: by 10.31.175.2 with HTTP; Fri, 15 Apr 2016 13:54:11 -0700 (PDT) In-Reply-To: <20160415204150.GE24565@calimero.vinschen.de> References: <20160415192350.GD24565@calimero.vinschen.de> <20160415204150.GE24565@calimero.vinschen.de> Date: Fri, 15 Apr 2016 20:54:00 -0000 Message-ID: Subject: Re: Cygwin 64bits gcc produces erroneous constants with the win32 headers. From: Nicolas Noble To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00385.txt.bz2 >> Right, but that isn't the same thing. I am well aware of the various >> issues tied with sizeof(long), > > Sorry, I wasn't aware of this since you wrote something along the lines > of gcc should make sizeof(long) == 4 which just doesn't make sense in an > LP64 environment. I can see how this was confusing, yes. I was trying to make the point that > One problem is that you're not supposed to use WinSock or the winsock > headers when compiling Cygwin applications. Use the Cygwin POSIX headers > and Cygwin socket functions instead. If you use WinSock headers and/or > functions and it breaks, you got to keep the pieces. Okay. See, that's something I didn't see documented anywhere :-) The documentation seems to say that it's fair game to use the Win32 API as long as you're linking the libraries in, and no mention of what is and isn't acceptable. Note that I'm not talking about mixing up Cygwin sockets and WinSock sockets. I'm simply talking about compiling a piece of code that is 100% WinSock aware, and exposes an API that doesn't even mention sockets. Think, I don't know, libcurl in easy mode for instance. Or maybe a "publish tweets on twitter" library. It should be acceptable that said static code be fully independent, and usable with cygwin code. Of course, solutions might be to say "sorry, it doesn't actually compile properly with Cygwin, please only use mingw-w64 to compile it, then link the resulting static .a file with your project" or "sorry, using Cygwin, you'll have to use the posix-version of the library, thus having to lose some amount of performance due to the Cygwin socket translation layer", but I find neither very appropriate. I'd rather have the code be compatible with cygwin's compiler and environment, while retaining the ability to fully use the WinSock API. > However, Mingw-w64 already contains a lot of changes to accommodate > the Cygwin LP64 environment, and incidentally there's already a type > available which does the right thing, so it might be a good idea to > suggest using that: > > #define FIONBIO _IOW('f',126,__ms_u_long) So you're saying that the w32api-headers cygwin package actually comes from mingw-w64 ? I can go and bug them instead then :-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple