Thread: BUG #17365: Error: redefinition of 'stat' in win32_port.h when including postgres.h

The following bug has been logged on the website:

Bug reference:      17365
Logged by:          Mario Emmenlauer
Email address:      mario@emmenlauer.de
PostgreSQL version: 14.1
Operating system:   Windows 10 with Clang-Cl 13.0.0 over MSVC 19.5
Description:

I'm compiling postgres with Microsoft Visual Studio 19.5. This generally
works well, thanks!

Then I build a wrapper library that uses `postgres.h` in my code. My code is
built using the LLVM Clang-Cl compiler frontend version 13.0.0 over
Microsoft Visual Studio 19.5. Generally, the Clang-Cl compiler frontend
works very well. But since updating PostgreSQL from 13.x to the 14.1
release, I get an error:
```
FAILED: CMakeFiles/DatabaseHandler.dir/src/BDAPGResult.cc.obj 
C:\BDA\ci\LLVM-13.0.0\bin\clang-cl.exe   -TP -DDATABASEHANDLER_DEBUG -DEBUG
-DFMT_LOCALE -DHasZLIB -DNOMINMAX -DWIN32 -DWIN64 -D_DEBUG -D_DEBUG_
-D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -D_WIN64
-IC:\data\ci-tmp\Debug\DatabaseHandler
-IC:\BDA\bld\XTJyb_7r\0\DatabaseHandler\include
-IC:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src
-IC:\data\ci-dst\Debug\include\server\port\win32 -imsvc
C:\data\ci-dst\Debug\include -imsvc C:\data\ci-dst\Debug\include\server
-imsvc C:\data\ci-dst\Tools\ipp\include -imsvc
C:\data\ci-dst\Tools\daal\include -imsvc C:\data\ci-dst\Tools\include -imsvc
C:\data\ci-dst\Debug\include\QtCore -imsvc
C:\data\ci-dst\Debug\mkspecs\win32-msvc -imsvc
C:\data\ci-dst\Debug\include\eigen3 -imsvc
C:\data\ci-dst\Debug\include\ITK-5.2 -imsvc
C:\data\ci-dst\Debug\include\QtGui /std:c++20 /MDd /Z7 -march=haswell
-Werror=pessimizing-move -Werror=redundant-move -Werror=range-loop-construct
 -Werror=range-loop-construct       /D_ITERATOR_DEBUG_LEVEL=0
/DWINVER=0x0A00 /D_WIN32_WINNT=0x0A00 /DDEBUG     /D_CRT_SECURE_NO_DEPRECATE
/D_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS  -Wextra -Werror=return-type
-Werror=uninitialized -Werror=unknown-pragmas -Werror=shadow -Werror=undef
-Werror=pointer-arith -DQT_DISABLE_DEPRECATED_BEFORE=0x050F00
-Werror=shift-count-overflow -Werror=string-plus-int
-Werror=nonportable-include-path -Werror=inconsistent-missing-override
-Werror=self-assign -Werror=self-assign-field -Werror=self-move
-Werror=braced-scalar-init -Werror=many-braces-around-scalar-init
-Werror=return-stack-address -Werror=delete-non-abstract-non-virtual-dtor
/W4  -Werror=return-stack-address
-Werror=delete-non-abstract-non-virtual-dtor    /DWIN32 /D_WINDOWS /GR /EHsc
/Zi /Ob0 /Od /RTC1 -MDd /Zc:__cplusplus -Zc:__cplusplus -permissive- -utf-8
-std:c++20 /showIncludes
/FoCMakeFiles\DatabaseHandler.dir\src\BDAPGResult.cc.obj
/FdDatabaseHandler.pdb -c --
C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc
In file included from
C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc:31:
In file included from C:\data\ci-dst\Debug\include\server\postgres.h:46:
In file included from C:\data\ci-dst\Debug\include\server/c.h:1362:
In file included from C:\data\ci-dst\Debug\include\server/port.h:26:
C:\data\ci-dst\Debug\include\server/port/win32_port.h(256,8): error:
redefinition of 'stat'
struct stat                                             /* This should match
struct __stat64 */
       ^
C:\Program Files (x86)\Windows
Kits\10\include\10.0.19041.0\ucrt\sys/stat.h(87,12): note: previous
definition is here
    struct stat
           ^
1 error generated.
```

I've recently also changed from c++17 to c++20, so maybe this can be
related? I keep the full compile command in above log in case there is
anything else dubious?
Any help would be greatly appreciated!

    Mario

Hi,

On Thu, Jan 13, 2022 at 09:11:45AM +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Then I build a wrapper library that uses `postgres.h` in my code. My code is
> built using the LLVM Clang-Cl compiler frontend version 13.0.0 over
> Microsoft Visual Studio 19.5. Generally, the Clang-Cl compiler frontend
> works very well. But since updating PostgreSQL from 13.x to the 14.1
> release, I get an error:
> ```
[...]
> C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc
> In file included from
> C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc:31:
> In file included from C:\data\ci-dst\Debug\include\server\postgres.h:46:
> In file included from C:\data\ci-dst\Debug\include\server/c.h:1362:
> In file included from C:\data\ci-dst\Debug\include\server/port.h:26:
> C:\data\ci-dst\Debug\include\server/port/win32_port.h(256,8): error:
> redefinition of 'stat'
> struct stat                                             /* This should match
> struct __stat64 */
>        ^
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.19041.0\ucrt\sys/stat.h(87,12): note: previous
> definition is here
>     struct stat
>            ^
> 1 error generated.
> ```

Note that postgres.h is intended for backend-side code, and I'm assuming that
your wrapper library is client code?  Have you tried using postgres_fe.h
instead?

Julien Rouhaud <rjuju123@gmail.com> writes:
> On Thu, Jan 13, 2022 at 09:11:45AM +0000, PG Bug reporting form wrote:
>> In file included from
>> C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc:31:
>> In file included from C:\data\ci-dst\Debug\include\server\postgres.h:46:
>> In file included from C:\data\ci-dst\Debug\include\server/c.h:1362:
>> In file included from C:\data\ci-dst\Debug\include\server/port.h:26:
>> C:\data\ci-dst\Debug\include\server/port/win32_port.h(256,8): error:
>> redefinition of 'stat'
>> struct stat                                             /* This should match
>> struct __stat64 */

> Note that postgres.h is intended for backend-side code, and I'm assuming that
> your wrapper library is client code?  Have you tried using postgres_fe.h
> instead?

Generally speaking, client code shouldn't include either of those,
but just libpq-fe.h.  Both postgres.h and postgres_fe.h are fairly
invasive in terms of setting up a programming environment that
matches our conventions for backend or frontend code respectively.
If you don't want to drink *all* of that Kool-Aid (which you likely
do not, if you are writing C++), you don't want those headers.

In particular, what I gather from the above is that postgres.h is
probably not the first #include in BDAPGResult.cc.  There are some
portability tricks we play that are dependent on not having read any
system header files before the inclusion of postgres[_fe].h, and
what this failure looks like to me is that you've broken one of
those tricks.  If you do insist on including one of those headers,
place it first.

            regards, tom lane

Hi Julien,

On 13.01.22 13:23, Julien Rouhaud wrote:
> On Thu, Jan 13, 2022 at 09:11:45AM +0000, PG Bug reporting form wrote:
>> The following bug has been logged on the website:
>>
>> Then I build a wrapper library that uses `postgres.h` in my code. My code is
>> built using the LLVM Clang-Cl compiler frontend version 13.0.0 over
>> Microsoft Visual Studio 19.5. Generally, the Clang-Cl compiler frontend
>> works very well. But since updating PostgreSQL from 13.x to the 14.1
>> release, I get an error:
>> ```
> [...]
>> C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc
>> In file included from
>> C:\BDA\bld\XTJyb_7r\0\DatabaseHandler\src\BDAPGResult.cc:31:
>> In file included from C:\data\ci-dst\Debug\include\server\postgres.h:46:
>> In file included from C:\data\ci-dst\Debug\include\server/c.h:1362:
>> In file included from C:\data\ci-dst\Debug\include\server/port.h:26:
>> C:\data\ci-dst\Debug\include\server/port/win32_port.h(256,8): error:
>> redefinition of 'stat'
>> struct stat                                             /* This should match
>> struct __stat64 */
>>        ^
>> C:\Program Files (x86)\Windows
>> Kits\10\include\10.0.19041.0\ucrt\sys/stat.h(87,12): note: previous
>> definition is here
>>     struct stat
>>            ^
>> 1 error generated.
>> ```
> 
> Note that postgres.h is intended for backend-side code, and I'm assuming that
> your wrapper library is client code?  Have you tried using postgres_fe.h
> instead?

Actually I do not really mean to include `postgres.h`. But I do want
to identify result types with `Oid vOID = ::PQftype(mResult.get(), vColumn);`
to check the result type. And the types seem to be defined in header
`catalog/pg_type.h` which only worked when `postgres.h` was included before.

I guess I'm off the standard track here. Its not completely mandatory for
me to identify the result types. But it was quite nice to be able to do
so.

Is this actually unsupported? Or am I doing something wrong?

All the best,

   Mario

On 13.01.22 16:28, Tom Lane wrote:
> In particular, what I gather from the above is that postgres.h is
> probably not the first #include in BDAPGResult.cc.  There are some
> portability tricks we play that are dependent on not having read any
> system header files before the inclusion of postgres[_fe].h, and
> what this failure looks like to me is that you've broken one of
> those tricks.  If you do insist on including one of those headers,
> place it first.

Yes, `postgres.h` not the first include in the file. Actually I can
not include it before `locale` on Linux, otherwise I get the following
error:

In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/locale:41:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/locale_facets_nonio.h:2010:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/x86_64-linux-gnu/c++/10/bits/messages_members.h:36:
/usr/include/libintl.h:61:14: error: expected ')'

The header `locale` is a dependency of my string handler, that in turn
includes quite a lot of other headers.

For PostgreSQL 13.x and earlier I could include `postgres.h` last, and
it worked on all platforms.

I can try and isolate my PostgreSQL calls and wrap them in some more
"pure" code, to avoid other includes. Or is there anything else I can
try?

All the best,

    Mario Emmenlauer

Hi,

On Sun, Jan 16, 2022 at 04:06:45PM +0100, Mario Emmenlauer wrote:
> 
> 
> Actually I do not really mean to include `postgres.h`. But I do want
> to identify result types with `Oid vOID = ::PQftype(mResult.get(), vColumn);`
> to check the result type. And the types seem to be defined in header
> `catalog/pg_type.h` which only worked when `postgres.h` was included before.
> 
> I guess I'm off the standard track here. Its not completely mandatory for
> me to identify the result types. But it was quite nice to be able to do
> so.
> 
> Is this actually unsupported? Or am I doing something wrong?

It's supported and multiple clien-side programs access those constants.
However you don't need to include postgres.h for that.  There are examples in
the tree that relies on OID defines if you want to check how it's done, for
instance src/bin/pg_dump/pg_dump.c.

Note that the OIDs aren't in pg_type.h anymore since pg 11.  Are you still
compiling against pg 10 or less?

Hi,

On 16.01.22 16:18, Julien Rouhaud wrote:
> Hi,
> On Sun, Jan 16, 2022 at 04:06:45PM +0100, Mario Emmenlauer wrote:
>> Actually I do not really mean to include `postgres.h`. But I do want
>> to identify result types with `Oid vOID = ::PQftype(mResult.get(), vColumn);`
>> to check the result type. And the types seem to be defined in header
>> `catalog/pg_type.h` which only worked when `postgres.h` was included before.
>>
>> I guess I'm off the standard track here. Its not completely mandatory for
>> me to identify the result types. But it was quite nice to be able to do
>> so.
>>
>> Is this actually unsupported? Or am I doing something wrong?
> 
> It's supported and multiple clien-side programs access those constants.
> However you don't need to include postgres.h for that.  There are examples in
> the tree that relies on OID defines if you want to check how it's done, for
> instance src/bin/pg_dump/pg_dump.c.
> 
> Note that the OIDs aren't in pg_type.h anymore since pg 11.  Are you still
> compiling against pg 10 or less?

Ah, this is very helpful! Indeed I developed this code against pg 9.x!
I can see the OID's now in `catalog/pg_type_d.h` and I found a related
commit that may be just exactly what you refer to:
9c0a0de4c9   Tom Lane   Switch client-side code to include catalog/pg_foo_d.h not pg_foo.h.

So I assume `catalog/pg_type_d.h` is really what I want! And it does not
need `postgres.h`. Thanks!

All the best,

    Mario