-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Chris Pickett on 12/29/2008 4:06 PM: > In this case, it still doesn't make a difference.
Which means that either AC_USE_SYSTEM_EXTENSIONS needs to be taught how to override 'cc -ansi' on mingw, or you are getting exactly what you asked for by asking for such a strict compilation environment, since strdup is _not_ an ansi function. > I looked at the > output from configure and it seems like it gets run after AC_PROG_CC > regardless, i.e. `checking for minix/config.h usability' comes after > `checking for unistd.h' and all the other C compiler stuff. Yeah, AC_USE_SYSTEM_EXTENSIONS has an implicit AC_REQUIRE([AC_PROG_CC]), so you are pretty much guaranteed that the compiler existence will be checked prior to determining the right flags/defines to enable various extensions. > > Nevertheless, maybe you want 1.patch. I'm not sure that it helps much, but if someone else agrees that adding the phrase "but after AC_PROG_CC" helped, I'll apply it. By the way, patches are easier to review with a ChangeLog entry, or even when created by 'git format-patch' with a commit message that can be converted into a ChangeLog entry. > Maybe you want 2.patch. I'm not sure if what I wrote is correct, but I > didn't find any indications to the contrary. There are four categories of functions: declared and linkable (for example, strcpy) undeclared and not linkable (for example, obstack_grow on non-glibc) declared but not linkable (for example, isnan, which POSIX says must be a macro and therefore does not have to be linkable. Also, things like freopen sometimes fall here, where platforms #define it to freopen64; and we have even seen broken headers that declare an unavailable function) undeclared but linkable (for example, strdup in your scenario) gnulib tends to be a pretty good collection of wisdom about which functions fall in the various categories. > > Finally, I suggest a macro that combines AC_REPLACE_FUNCS and > AC_CHECK_DECLS and that this new macro become the recommended usage. On > the other hand, is there ever a time that you explicitly don't want a > function to be listed in both AC_REPLACE_FUNCS and AC_CHECK_DECLS? If > not, maybe you can simply get AC_REPLACE_FUNCS to run AC_CHECK_DECLS. For backward compatibility reasons, we can't change AC_REPLACE_FUNCS. Your suggestion of a new macro that tests for both linkability and declaration in one go, may have merit, but as gnulib has discovered, sometimes one of the two tests is unnecessary, leading to unnecessary time spent during configure runs (or even misleading or wrong answers, in the case of isnan). I'm not bothered enough by it myself to write a macro, but I'm not opposed to reviewing such a patch, so care to attempt writing such a patch? It will probably be non-trivial, so you may want to take care of copyright assignment papers first. As to your proposed 2.patch, I'll have to think about whether that wording helps, or whether yet another wording also makes things more clear. But I will probably end up committing at least something that reminds people that AC_REPLACE_FUNCS only kicks in on failed links, and that failed declarations are also worth checking. - -- Don't work too hard, make some time for fun as well! Eric Blake [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklZjIsACgkQ84KuGfSFAYA2qQCffj0Me02lz3xpPmInzVR+Obw9 j94AoNdGLVaZaYEmRVaRE9SJP0t3YDiR =7TsK -----END PGP SIGNATURE-----
