Обсуждение: BUG #18995: Building with GCC 14 fails: incompatible pointer struct pam_message

The following bug has been logged on the website:

Bug reference:      18995
Logged by:          Andrew Watkins
Email address:      awatkins1966@gmail.com
PostgreSQL version: 17.5
Operating system:   Solaris 11.4
Description:

Hello,
Not sure if a Oracle Solaris problem or not.

First, PostgreSQL 17.5 with GCC v13 builds cleaning and runs on Solaris
11.4, but building with GCC v14 I get the following:

gcc -m64 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
-Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation
-O2 -I../../../src/include  -D_POSIX_PTHREAD_SEMANTICS
-I/usr/include/libxml2   -c -o auth.o auth.c
auth.c:101:9: error: initialization of 'int (*)(int,  struct pam_message **,
struct pam_response **, void *)' from incompatible pointer type 'int
(*)(int,  const struct pam_message **, struct pam_response **, void *)'
[-Wincompatible-pointer-types]
  101 |         &pam_passwd_conv_proc,
      |         ^
auth.c:101:9: note: (near initialization for 'pam_passw_conv.conv')
gmake[3]: *** [<builtin>: auth.o] Error 1
gmake[3]: Leaving directory
'/home/andrew/src/postgresql-17.5/src/backend/libpq'
gmake[2]: *** [common.mk:37: libpq-recursive] Error 2
gmake[2]: Leaving directory '/home/andrew/src/postgresql-17.5/src/backend'
gmake[1]: *** [Makefile:42: all-backend-recurse] Error 2
gmake[1]: Leaving directory '/home/andrew/src/postgresql-17.5/src'
gmake: *** [GNUmakefile:11: all-src-recurse] Error 2

Thanks,
Andrew

PG Bug reporting form <noreply@postgresql.org> writes:
> First, PostgreSQL 17.5 with GCC v13 builds cleaning and runs on Solaris
> 11.4, but building with GCC v14 I get the following:

> gcc -m64 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
> -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv
> -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation
> -O2 -I../../../src/include  -D_POSIX_PTHREAD_SEMANTICS
> -I/usr/include/libxml2   -c -o auth.o auth.c
> auth.c:101:9: error: initialization of 'int (*)(int,  struct pam_message **,
> struct pam_response **, void *)' from incompatible pointer type 'int
> (*)(int,  const struct pam_message **, struct pam_response **, void *)'
> [-Wincompatible-pointer-types]
>   101 |         &pam_passwd_conv_proc,
>       |         ^
> auth.c:101:9: note: (near initialization for 'pam_passw_conv.conv')

This doesn't look like a GCC version problem, but like a discrepancy
in the PAM header files, to wit, "const" or not in the expected
signature of pam_passwd_conv_proc.  Can you verify whether or not
pam_appl.h and its subsidiary headers changed?

On my Linux box I find this in /usr/include/security/_pam_types.h:

struct pam_conv {
    int (*conv)(int num_msg, const struct pam_message **msg,
        struct pam_response **resp, void *appdata_ptr);
    void *appdata_ptr;
};

but it seems that "const" is missing in yours.  I guess an alternative
theory is that it was inconsistent all along but you hadn't previously
tried to build --with-pam.

            regards, tom lane

I wrote:
> This doesn't look like a GCC version problem, but like a discrepancy
> in the PAM header files, to wit, "const" or not in the expected
> signature of pam_passwd_conv_proc.  Can you verify whether or not
> pam_appl.h and its subsidiary headers changed?

I had a feeling we'd seen this before, and after digging in the
archives indeed we have:

https://www.postgresql.org/message-id/flat/16415.1184285944%40sss.pgh.pa.us#a0a2fac693665cc517f761e24f222574

So I take back the guess that it's not about GCC version.  What
seems more likely now is that it's been a warning right along,
which you have been ignoring, and GCC 14 has decided to promote
it to an error.

We could perhaps install a configure check to see if this argument
is expected to be const or not.  But given the shortage of reports,
I think it'd be sufficient to do what I suggested in that 2007
thread:

>> The main issue in my mind would be how to determine whether to use
>> const or not.  If all Solaris releases are like this, and can be
>> expected to stay that way, I'd be inclined to just put a "#define
>> PAM_CONV_PROC_NOT_CONST" in include/port/solaris.h and drive the
>> function declaration off that.

As a short-term workaround, GCC has probably got a command-line
option to knock the error back down to a warning.

            regards, tom lane

Andrew Watkins <awatkins1966@gmail.com> writes:
> Sorry, for digging up an old problem . I did some searching of the archive
> but never found that link going back to 2007.

No trouble.  I'm surprised we never did anything about it, TBH.

Reviewing our buildfarm members, it looks like none of the current
Solaris or illumos/OpenIndiana animals use --with-pam, which is a
bit sad but explains why we don't see any warnings in the farm.
And I guess end users have just ignored the warning so far.
But we'll have to up our game if GCC is going to start making this
an error by default.

            regards, tom lane

Andrew Watkins <awatkins1966@gmail.com> writes:
>  You are right Solaris is missing "const"

> struct pam_conv {
>         int (*conv)(int, struct pam_message **, struct pam_response **,
> void *);
>         void *appdata_ptr;
> };

So I tried to replicate this issue on an OpenIndiana VM (OI 2024.04),
and got no failure.  Digging into /usr/include/security/pam_appl.h,
I found the reason:

struct pam_conv {
#ifdef _PAM_LEGACY_NONCONST
        int (*conv)(int, struct pam_message **,
#else
        int (*conv)(int, const struct pam_message **,
#endif
            struct pam_response **, void *);
        void *appdata_ptr;              /* Application data ptr */
};

So that's just annoying as all get-out: it means some "Solaris"
platforms do have this declaration with the "const", and even
there it's going to be dependent on compilation environment.

I still see a way to avoid a configure check though: let's make
src/include/port/solaris.h "#define _PAM_LEGACY_NONCONST".
That should make OpenIndiana enough like other Solaris-alikes
for the purpose, and we can also use that same symbol to cue
our code how to declare the callback function.

Or we could create a configure check, but that seems like a lot
of work, and it would add some extra time to everybody's build.

            regards, tom lane

I wrote:
> I still see a way to avoid a configure check though: let's make
> src/include/port/solaris.h "#define _PAM_LEGACY_NONCONST".
> That should make OpenIndiana enough like other Solaris-alikes
> for the purpose, and we can also use that same symbol to cue
> our code how to declare the callback function.

Done that way at

https://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=635a856279ef55074dfc7a2a96c7fd686b5ff015

If you can confirm that you get a clean build with this patch,
I'd appreciate it.

            regards, tom lane