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: <3E4ED533.3090504@ece.gatech.edu>
Date: Sat, 15 Feb 2003 19:02:59 -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
To: Max Bowsher <maxb AT ukf DOT net>
CC: cygwin AT cygwin DOT com
Subject: Re: [Problem] mempcpy is missing?  (FAQ alert)
References: <20030215210505 DOT GA29578 AT redhat DOT com> <010601c2d537$decb05c0$78d96f83 AT pomello> <20030215215840 DOT GA3446 AT redhat DOT com> <3E4EC408 DOT 8070500 AT ece DOT gatech DOT edu> <004201c2d546$ba7482a0$78d96f83 AT pomello> <3E4ECC52 DOT 50609 AT ece DOT gatech DOT edu> <005101c2d54a$e70732a0$78d96f83 AT pomello>
In-Reply-To: <005101c2d54a$e70732a0$78d96f83@pomello>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Max Bowsher wrote:

> 3 things:
> - The issue here was mempcpy, not memcpy

okay, fine...

> - Cygwin *doesn't* have a memcpy.h

It was simply an example.  sure, memPcpy is declared in string.h.  The 
point is, the declaration is found, but the (test) link fails (during 
configury).  and because it fails, your package provides its own 
implementation -- without realizing that the declaration in string.h 
conflicts.  Thus, compile time failure when you actually build the 
project itself.

> - I still don't understand what you are going to fix - am I missing the obvious?

It sounded to me like there was a problem in libintl's headers (and 
possible its configury) where it did not account for the possibility of 
a prior declaration.  This is bad coding.

When you provide a replacement function, you should always 
define/declare it as

my_foo()

not

foo()

or use some unique prefix like libintl_foo().  Then, your code should 
call LIBINTL_FOO( (args) ).  Now, if the function is in the system libs, 
then you want

#define LIBINTL_FOO(a)  foo(a)

but if it isn't found, then you want

#define LIBINTL_FOO(a)  libintl_foo(a)

Now, there are lots of little niggles that can bite you.  I figured I 
would have to work at this a bit -- and I'd save this thread and get 
around to it when I next update gettext.  BUT, I really didn't read the 
initial message that closely; "libintl has a problem"  "Okay, that's my 
job to fix it."

Am I wrong? Without Chris's change to cygwin.din, is the problem 
actually somewhere *else* and not in libintl.h/etc?  <excluding also any 
possibility of huge #ifdef CYGWIN structures spinkled all over newlib. 
ain't gonna happen>

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