Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Message-ID: <3E4EC30E.4040404@ece.gatech.edu>
Date: Sat, 15 Feb 2003 17:45:34 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: gmane.os.cygwin
To: cygwin AT cygwin DOT com
Subject: Re: [Problem] mempcpy is missing?  (FAQ alert)
References: <00d001c2d530$02497430$78d96f83 AT pomello> <20030215210505 DOT GA29578 AT redhat DOT com>
In-Reply-To: <20030215210505.GA29578@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

> So, the cygwin bug report is noted and appreciated.  We'll fix this
> eventually.  However, the "correct" fix is to modify the configury
> mechanism which trips up on this in libintl.
> 
> I guess I can't get by without giving the long answers to reports
> like this...  We should add this to the FAQ.

That is, you should check both for the appropriate header, and for the 
function.  Some (bad) configure.in's check only for "memcpy.h" (or 
whatever), but don't check that the function memcpy() can actually be 
linked.  The right incantation is

in configure.in:

AC_CHECK_HEADERS([memcpy.h ...])
AC_CHECK_FUNCS([memcpy ...])

And in your C code, guard with

#if defined(HAVE_MEMCPY_H) && defined(HAVE_MEMCPY)
memcpy code here...
#endif

Technically, this is an autoconf question -- but it crops up on cygwin 
often.  Mainly, because there are so many "regular C library functions" 
that are missing from newlib, but slowly get added to it (and hence, 
added to cygwin) such that the cygwin exports are often behind -- and we 
have the header <direct from newlib> but don't make the function 
visible.  Thus, we're a good testbed for revealing these third-party 
packages which make too many assumptions in their configury.

Chris is right -- this is really a problem with the third party package. 
  But we probably need a blurb in the FAQ about it anyway.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/