(As I'm not on the GTK mailing list, this mail won't get to that list,
so, if you reply, include enough of the reply that they know what you're
replying to....)
> This is from config.log:
>
> configure:5164: checking for getpwuid_r
> configure:5184: xlc_r -o conftest -g -D_REENTRANT -D_THREAD_SAFE conftest.c
> 1>&5
> configure:5209: checking whether getpwuid_r is posix like
> configure:5222: xlc_r -c -g -D_REENTRANT -D_THREAD_SAFE conftest.c 1>&5
> "configure", line 5218.11: 1506-098 (E) Missing argument(s).
>
> The return code from xlc_r is 0 in this case, so configure assumes
> that the test passes.
>
> I looked inside the configure script, and this is what is going on:
>
> ==============================================================================
> echo "configure:5209: checking whether getpwuid_r is posix like" >&5
> # getpwuid_r(0, NULL, NULL, 0) is the signature on
> # solaris, if that is not found, the prog below won't
> # compile, then the posix signature is assumed as
> # the default.
> cat > conftest.$ac_ext <<EOF
> #line 5215 "configure"
> #include "confdefs.h"
> #include <pwd.h>
> int main() {
> getpwuid_r(0, NULL, NULL, 0);
> ; return 0; }
> EOF
> ==============================================================================
>
> What is happening is, xlc_r compiles this program, and flags it with the
> "(E) Missing arguments" warning.
Missing arguments is only a *warning*? Yeesh....
Is there a flag that can be passed to "xlc" to get it to treat procedure
calls not matching the function prototype as an *error*, so that it
refuses to produce an object file, and exits with a non-zero exit
status? If so, perhaps the "autoconf" stuff needs to use that flag when
the compiler is "xlc". (And, frankly, everything else arguably needs to
use that flag as well; I suspect that in at least 99 44/100% of the
cases where a function call doesn't match the prototype, that isn't
intentional, and won't work correctly....)
The return code from xlc_r in this case is
> 0, so configure assumes that the test passed, and gives the
> prototype as int getpwuid_r(uid_t, struct passwd *, char *, int).
>
> However, the POSIX prototype for this function is:
> int getpwuid_r(uid_t, struct passwd *, char * , size_t , struct passwd **)
>
> (See http://www.opengroup.org/onlinepubs/007908799/xsh/getpwuid.html)
>
> So I think that this test is incorrect. It should test for the POSIX
> version of getpwuid_r() first, not the other one.
The comment seems to imply that the intent of the test is to have the
compile fail with the POSIX version of "getpwuid_r()", so that
if the Solaris version (which may have antedated the POSIX
version) is found the compile succeeds, and the configure script
assumes it's not the POSIX version;
if some other version is found, the compile fails (assuming your
compiler doesn't, for some unknown reason, treat prototype
mismatches as warnings rather than errors :-( ), and the
configure script assumes the other version is the POSIX version;
so I think the test is doing the right thing, except for assuming that
the compiler treats prototype mismatches sanely, which it sounds as if
"xlc" doesn't, at least by default.
