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