X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:cc:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	 q=dns; s=default; b=YXEYuQDBouyV8EReBnzRW2byZhCbY6xJSF+7950dJkz
	7rJR+jdUsMTcJyhYjRo6l7LleoALdY3MesQOTWbjpULF1e2sF9zMvVLLoIrkHwFA
	B/taFKEYbyz/NVsjcdhbUa3jHAURDP5JbE9GU7ZdmuUZMqKbQ8ZHDORANdWmdpIA
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:cc:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	 s=default; bh=e3F86zKODS7mDjRV78Wa2tB5kxY=; b=dLz69Zc5fN8iDc+ZB
	N+lRD060UNXZz75J0i1xnofdcGPCjeu8Dol+Pc+1FIVj6tvSWvwL0/GSIsc5J12o
	tRXx1s+ftINpT09O/BaD6PsX5gfPL0wiWu6xqI9Aal/yYsSIuftdbnJGGyV3TGcH
	vHluIfbxe1tO3ExlVNjt55g9sE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1
From: Fedin Pavel <p DOT fedin AT samsung DOT com>
To: "'Greg Turner'" <gmt AT malth DOT us>
Cc: cygwin AT cygwin DOT com
References: <CA+VB3NQhfaRnu2ZzbSgOKFG65vf4hp0Xbcpr-WThf+KNSqjmPg AT mail DOT gmail DOT com>
In-reply-to: <CA+VB3NQhfaRnu2ZzbSgOKFG65vf4hp0Xbcpr-WThf+KNSqjmPg@mail.gmail.com>
Subject: RE: Suggestion: improve cross-compiling ability
Date: Tue, 09 Jul 2013 11:13:34 +0400
Message-id: <001f01ce7c73$d371d8e0$7a558aa0$%fedin@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id r697Dpvl017520

 Hello!

> I don't know anything about _BSDTYPES_DEFINED but it sounds like some
> autotools solution is already in place, which defines
> __{u_char,daddr_t}_defined; it's hard to imagine a patch fixing that
> autotools stuff to correctly differentiate cbuild from ctarget would be
> poo-poo'ed by the glibc folks (or, for that matter, whatever upstream
> glibc's autotools scripts might be relying on for this).

 This is not about autotools. This particular code fragment does not rely on autotools. It's just the following text in .h file:
--- cut ---
#ifndef __u_char_defined
typedef __u_char u_char;
typedef __u_short u_short;
typedef __u_int u_int;
typedef __u_long u_long;
typedef __quad_t quad_t;
typedef __u_quad_t u_quad_t;
typedef __fsid_t fsid_t;
# define __u_char_defined
#endif
#ifndef __daddr_t_defined
typedef __daddr_t daddr_t;
typedef __caddr_t caddr_t;
# define __daddr_t_defined
#endif
--- cut ---

 Looks like this should work for some hypothetical system which doesn't have things like u_char etc. Here __u_char and friends appear to be own versions, defined somewhere by glibc code itself. This code causes 'type redefinition' error because we actually have u_char but don't have accompanying indicator.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



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