Christopher Faylor wrote: > On Sat, Feb 15, 2003 at 08:22:49PM -0000, Max Bowsher wrote: >> Christopher Faylor wrote: >>> On Sat, Feb 15, 2003 at 12:35:56PM -0700, Roger Sayle wrote: >>>> I apologise if this is the wrong list to report bugs. I have >>>> searched the archive and haven't been able to find a reference to >>>> mempcpy. >>> >>> As you have discovered, mempcpy is not provided. If a configure >>> script detects it, the configure script is broken. >> >> As he said, his configure script correctly decides #undef >> HAVE_MEMPCPY >> >> But then the source tries to define its own replacement mempcpy - >> but it can't, because that clashes with Cygwin's headers. So this >> really is Cygwin's fault. > > Um. This is not the first time something like this has come up. And > it won't be the last. There are a number of things in newlib that > are not exported by cygwin. The definition of mempcpy has apparently > been in the header since July of 2002. > > It is trivial to export the function or protect the header but that is > besides the point. The whole point of systems like configure is to > provide pain-free ways to work around system quirks. So the best fix > is to modify the libintl source so that this isn't a problem for older > versions of cygwin (which we obviously can't fix retroactively) or > other hypothetical systems out there which may have similar problems.
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. So, when fixing the problem is orders of magnitude easier than making a workaround, it's easy to see which will happen! :-) 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/
