Charles Wilson wrote: > 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)
Ah. Now I understand. Thanks for explaining that. > 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? No, you are right. 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/
