Mail Archives: cygwin/2003/02/15/16:57:28
On Sat, Feb 15, 2003 at 09:19:05PM -0000, Max Bowsher wrote:
>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.
Wow, are you related to Rube Goldberg?
#define mempcpy foo_mempcpy
#include <string.h>
#undef mempcpy
Or, go the other way around and
do a '#define mempcpy libintl_mempcpy' in an appropriate header.
>So, when fixing the problem is orders of magnitude easier than making a
>workaround, it's easy to see which will happen! :-)
This is *not* a workaround. This is making configury work for what
it was designed to do.
If I buy an amplifier for my cable system because I get poor quality
cable signal, and find that channel 5 isn't being amplified, I could go
to the cable company and complain or I could complain to the amplifier
manufacturer.
Probably both make sense but surely the amplifier should be doing what
it is designed to do.
In this case, the whole point of configuration scripts is to work around
OS build environment differences. "In an ideal world" is exactly what
configure is not supposed to assume.
Of course we're going to fix cygwin. I just checked in a fix. While I
assume this will probably be the end of it since no one will go to the
effort of trying to fix libintl's configury and, if they did, there
would probably be no official response anyway, the complete and correct
fix is to modify libintl. Then people using cygwin 1.3.10 - 1.3.20
could benefit too.
cgf
--
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 -