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:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding; q=dns; s=default; b=EUr
	7dfJBO61VsJW0PkdslnqbNWI+1GbWEL2v39RSIiriLaVyUT3qmjUsW060V/BwH8M
	On9hKYdvyV3m22StSXPVp0IGyU4uIZByjFKby7s5Xeak682uEGjP3jXiek00JCsg
	e2Y47YBJM6Ay8Ugc+VOIK9D0XvKIMiCQBHCkCi+M=
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:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding; s=default; bh=hCL9Konec
	6raFoKLzN1cErHaGCM=; b=mWSvNzGEYHHcCx8j4HhFU6P2wa/qM54RuhWnk32zt
	yZQbKueorJtd5w7TuTZlQ3NxKG9fB9txpLTQN9AguCd0EIoJyV6DNTVsZ9yTcz/J
	YJ1iXKWSICwYZjnOcc1vktYhK0xeCOmG9ltMmfopvmTV6b0Ho0QghNGmn1YT0LV4
	QQ=
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=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1
Message-ID:	<514CB23A.2050602@hones.org.uk>
Date:	Fri, 22 Mar 2013 19:34:18 +0000
From:	Cliff Hones <cliff AT hones DOT org DOT uk>
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Problem with _WIN32 preprocessor symbol and libusb
X-Spam-Score:	-2.5 (--) (knockando.watchfront.net.uk)
X-Spam-Report:	knockando.watchfront.net.uk has scanned this email for spam. Results:- RP_MATCHES_RCVD=-2.497 (total -2.5, current threshold 5.0)

The libusb package uses the presence of _WIN32 to determine which
calling convention to use for the library externals - if _WIN32 is
defined it uses WINAPI.  [See /usr/include/libusb-1.0/libusb.h.]

There is of course the question of whether it is/was sensible to use
WINAPI when the package is compiled for Cygwin, but (as the header
points out) this doesn't really matter as long as the same is
used for compiling the library and compiling user applications.

Unfortunately the default has been changed recently.  _WIN32 used to
be defined by default in the Cygwin environment (so the current
libusb package is using WINAPI), but some time between last December
and now this was changed so _WIN32 is no longer defined.  I see from
mail archives this was intentional - but it has unfortunately broken
usage of libusb.

I assume the absence of _WIN32 is permanent, in which case libusb
needs to be reissued.

Note - there is of course a trivial workaround until libusb is reissued -
simply define _WIN32 explicitly in any source including libusb.h.

-- Cliff

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

- Raw text -