Package Details: mingw-w64-postgresql 16.1-1

Git Clone URL: (read-only, click to copy)
Package Base: mingw-w64-postgresql
Description: Sophisticated object-relational DBMS (mingw-w64)
Upstream URL:
Keywords: mingw mingw-w64 postgresql postgresql-libs
Licenses: custom:PostgreSQL
Conflicts: mingw-w64-postgresql-libs
Provides: mingw-w64-postgresql-libs
Replaces: mingw-w64-postgresql-libs
Submitter: Schala
Maintainer: Martchus
Last Packager: Martchus
Votes: 14
Popularity: 0.000000
First Submitted: 2016-08-19 22:49 (UTC)
Last Updated: 2023-11-10 19:26 (UTC)

Pinned Comments

Martchus commented on 2017-06-03 13:19 (UTC) (edited on 2019-01-28 13:06 (UTC) by Martchus)

Important note

This package must be built in a clean chroot or at least without the previous version being installed. Otherwise PostgeSQL's build system seems to pick up the installed version of certain libraries rather than the version produced by the current build. (You would get a linker error like undefined reference to 'AllocSetContextCreateExtended'.)

All my packages are managed at GitHub where you can also contribute directly: There also exist a binary repository:

Latest Comments

1 2 3 4 Next › Last »

davidalb97 commented on 2022-11-17 02:49 (UTC)

@Martchus Sorry for taking this long to answer and you were right, I was using Manjaro at the time and OpenSSL was still outdated on their stable branch.

Martchus commented on 2022-03-15 13:58 (UTC)

@davidalb97 Did you already upgrade to OpenSSL 3.0? I wouldn't be surprised if it doesn't work out of the box at this point. See my comment on For now I'd suggest to stick to OpenSSL at You can also just use my binary repository which is also still at OpenSSL 1.1. I will do a rebuild similar to at some point but it makes sense to do it in accordance with the regular packages (e.g. to be able to pick-up necessary patches in accordance without re-inventing the wheel).

davidalb97 commented on 2022-03-15 13:20 (UTC) (edited on 2022-03-15 14:12 (UTC) by davidalb97)

Not building for me, you know where can I find these "eay32" or "crypto" libraries?

checking for library containing CRYPTO_new_ex_data... no
configure: error: library 'eay32' or 'crypto' is required for OpenSSL
==> ERROR: A failure occurred in build().

Martchus commented on 2020-02-14 14:02 (UTC)

@Onoketa I was able to build in a clean chroot and other users could build it as well. Hence I assume you've missed the pinned comment and have a previous version installed during the build. Also be aware that the static Qt 5 package won't build against the latest PostgreSQL yet:

Onoketa commented on 2020-02-14 13:29 (UTC)

/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: libpqwalreceiver.o:libpqwalreceiver.c:(.text+0x38b): undefined reference to pg_strtoint32' /usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: libpqwalreceiver.o:libpqwalreceiver.c:(.text+0xcf5): undefined reference topg_strtoint32' /usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: libpqwalreceiver.o:libpqwalreceiver.c:(.text+0x13e5): undefined reference to `AllocSetContextCreateInternal' collect2: ld returned 1 exit status

luntik2012 commented on 2019-01-28 13:03 (UTC)

yes, it works after removing package. please, add this to pinned comment

Martchus commented on 2019-01-28 12:24 (UTC) (edited on 2019-01-28 12:26 (UTC) by Martchus)

Please don't flag packages in case of a "compilation error for about two months". The problem was initially only reported by one user so I assumed that it would be a local issue and didn't care too much. Besides the initial comment was not even including the linker invocation itself. How should I investigate a linker error without knowing the linker flags?

My own build conduced in a clean chroot succeeded. I assume you guys all didn't use a clean chroot and are instead building the package while the previous version is still installed on the system. Can you at least try to uninstall the previous version before? Judging by the linker line from @doragasu comment I assume gcc/ld will pick up the installed version rather than the newly built version. That seems to be a limitation of PostgreSQL's build system. It wouldn't be the first package of that kind (e.g. Qt's build system suffers from the same problem).

luntik2012 commented on 2019-01-28 12:10 (UTC)

the same error. any updates?

doragasu commented on 2019-01-28 07:17 (UTC) (edited on 2019-01-28 07:20 (UTC) by doragasu)

I am also consistently having a linker error issue:

i686-w64-mingw32-gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4    -shared -static-libgcc -o libpqwalreceiver.dll  libpqwalreceiver.o win32ver.o -L../../../../src/port -L../../../../src/common -L../../../../src/interfaces/libpq -lpq -Wl,-O1,--sort-common,--as-needed  -Wl,--allow-multiple-definition -Wl,--disable-auto-import -L/usr/i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/lib   -lintl -L../../../../src/backend -lpostgres -lpgcommon -lpgport -lintl -lxml2 -lssl -lcrypto -lz -lm  -lws2_32 -Wl,--export-all-symbols -Wl,--out-implib=liblibpqwalreceiver.dll.a
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: libpqwalreceiver.o:libpqwalreceiver.c:(.text+0x143e): undefined reference to `AllocSetContextCreateExtended'
collect2: error: ld returned 1 exit status

Might be related to this:

Martchus commented on 2018-12-08 18:32 (UTC)

I was able to build the latest version. Not sure what is different in your case. You can checkout the .BUILDINFO of to find out what's different in your build environment.