Christopher Faylor wrote:
That is, you should check both for the appropriate header, and for the function. Some (bad) configure.in's check only for "memcpy.h" (or whatever), but don't check that the function memcpy() can actually be linked. The right incantation isSo, the cygwin bug report is noted and appreciated. We'll fix this eventually. However, the "correct" fix is to modify the configury mechanism which trips up on this in libintl.I guess I can't get by without giving the long answers to reports like this... We should add this to the FAQ.
in configure.in:
AC_CHECK_HEADERS([memcpy.h ...])
AC_CHECK_FUNCS([memcpy ...])
And in your C code, guard with
#if defined(HAVE_MEMCPY_H) && defined(HAVE_MEMCPY)
memcpy code here...
#endif
Technically, this is an autoconf question -- but it crops up on cygwin often. Mainly, because there are so many "regular C library functions" that are missing from newlib, but slowly get added to it (and hence, added to cygwin) such that the cygwin exports are often behind -- and we have the header <direct from newlib> but don't make the function visible. Thus, we're a good testbed for revealing these third-party packages which make too many assumptions in their configury.
Chris is right -- this is really a problem with the third party package. But we probably need a blurb in the FAQ about it anyway.
--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/
