Mail Archives: cygwin/2003/02/15/19:03:10
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/
- Raw text -