Date: Thu, 12 Jan 2006 15:48:35 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Define _POSIX_SOURCE in cygwin's features.h?
Message-ID: <20060112204835.GC2887@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20060112173104 DOT GA30011 AT trixie DOT casa DOT cgf DOT cx> <43C69B77 DOT 1070304 AT users DOT sourceforge DOT net> <20060112182017 DOT GD30108 AT trixie DOT casa DOT cgf DOT cx> <43C6BBA5 DOT 9000809 AT users DOT sourceforge DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43C6BBA5.9000809@users.sourceforge.net>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Thu, Jan 12, 2006 at 02:27:17PM -0600, Yaakov S (Cygwin Ports) wrote:
>Christopher Faylor wrote:
>>I guess more subtext that you could read into my request would be that
>>we would make the headers work as closely as possible to linux when
>>_POSIX_SOURCE is defined.  The key here is to make things look more
>>like linux so that programs port more easily.
>
>Right now, all _POSIX_SOURCE seems to do is exclude a number of
>constants and functions from being defined, supposedly because they
>aren't part of the POSIX standard.
>
>Now, newlib != glibc, but the examples I mentioned before could be
>compared to their glib counterparts (see below regarding
><sys/select.h>).

Wouldn't that follow from my "we would make the headers work as closely
as possible to linux"?

>>So, that would imply that "we" really should actively fix up the
>>headers to make sure that it is properly handled.
>
>OK, but I think these are uncommon cases; I've built a *LOT* of
>packages of all types, and this has not generally been a problem.

I would not expect that there would ever be a case where defining
_POSIX_SOURCE would help you on cygwin since you have discovered that it
is not correctly handled in cygwin headers.

>> I was hoping for concrete examples.  Do you have any?
>
>gmime2:
>
>gmime-gpg-context.c: In function `gpg_ctx_op_step':
>gmime-gpg-context.c:1089: error: `fd_set' undeclared (first use in this
>function)
>gmime-gpg-context.c:1089: error: (Each undeclared identifier is reported
>only once
>gmime-gpg-context.c:1089: error: for each function it appears in.)
>gmime-gpg-context.c:1089: error: parse error before "rdset"
>gmime-gpg-context.c:1096: error: `rdset' undeclared (first use in this
>function)
>gmime-gpg-context.c:1114: error: `wrset' undeclared (first use in this
>function)
>gmime-gpg-context.c:1124: error: `wrsetp' undeclared (first use in this
>function)
>
>fd_set is defined in <sys/types.h> (which is also called by
><sys/select.h>, but only if !defined(_POSIX_SOURCE)), but with this
>condition:

Of course if cygwin uses _POSIX_SOURCE incorrectly it will cause
problems.

I'm talking about fixing that.

>Since _POSIX_SOURCE on Cygwin doesn't add anything, I can't remember a
>case that I've had to *add* such a define.

I'm talking about cases where source code to be ported would have ported
more easily because it relied on _POSIX_SOURCE turning on some
functionality that was available in cygwin (the cygwin header file
problems notwithstanding).

cgf

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