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: <010601c2d537$decb05c0$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: <cygwin AT cygwin DOT com>
References: <20030215210505 DOT GA29578 AT redhat DOT com>
Subject: Re: [Problem] mempcpy is missing?  (FAQ alert)
Date: Sat, 15 Feb 2003 21:19:05 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Christopher Faylor wrote:
> On Sat, Feb 15, 2003 at 08:22:49PM -0000, Max Bowsher wrote:
>> Christopher Faylor wrote:
>>> On Sat, Feb 15, 2003 at 12:35:56PM -0700, Roger Sayle wrote:
>>>> I apologise if this is the wrong list to report bugs.  I have
>>>> searched the archive and haven't been able to find a reference to
>>>> mempcpy.
>>>
>>> As you have discovered, mempcpy is not provided.  If a configure
>>> script detects it, the configure script is broken.
>>
>> As he said, his configure script correctly decides #undef
>> HAVE_MEMPCPY
>>
>> But then the source tries to define its own replacement mempcpy -
>> but it can't, because that clashes with Cygwin's headers. So this
>> really is Cygwin's fault.
>
> Um.  This is not the first time something like this has come up.  And
> it won't be the last.  There are a number of things in newlib that
> are not exported by cygwin.  The definition of mempcpy has apparently
> been in the header since July of 2002.
>
> It is trivial to export the function or protect the header but that is
> besides the point.  The whole point of systems like configure is to
> provide pain-free ways to work around system quirks.  So the best fix
> is to modify the libintl source so that this isn't a problem for older
> versions of cygwin (which we obviously can't fix retroactively) or
> other hypothetical systems out there which may have similar problems.

Yes, in an ideal world, configure would deal with this - but unless you have
a better idea, the only way I can think of dealing with it is to copy the
problem header to the compilation directory, parse out the problem
declaration somehow, and modify the compiler invocations with an
additional -I option. Messy and fragile. So, when fixing the problem is
orders of magnitude easier than making a workaround, it's easy to see which
will happen! :-)

Max.


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