This way we don't need RANLIB anymore, making it a bit simpler for the meson build to generate Makefile.global for PGXS compatibility. FreeBSD, NetBSD, OpenBSD, the only platforms where we didn't use AROPT=crs, all have supported the 's' option for a long time. On macOS we ran ranlib after installing a static library. This was added a long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent macOS versions. This is removed now. Based on discussion with Tom, I left the 'touch' at the end of static libraries generation, added in 826eff57c4c, in place. While it looks like current versions of Apple's ar/ranlib don't need it, it was needed not too long ago. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
Move DLSUFFIX from makefiles into header files for all platforms. Move the DLSUFFIX assignment from src/makefiles/ to src/templates/, have configure read it, and then substitute it into Makefile.global and pg_config.h. This avoids the need for all makefile rules that need it to locally set CPPFLAGS. It also resolves an inconsistent setup between the two Windows build systems. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/2f9861fb-8969-9005-7518-b8e60f2bead9@enterprisedb.com
Move the platform-dependent logic that sets CFLAGS_SL from src/makefiles/Makefile.foo to src/template/foo, so that the value is determined at configure time and thus is available while running configure's tests. On a couple of platforms this might save a few microseconds of build time by eliminating a test that make otherwise has to do over and over. Otherwise it's pretty much a wash for build purposes; in particular, this makes no difference to anyone who might be overriding CFLAGS_SL via a make option. This patch in itself does nothing with the value and thus should not change any behavior, though you'll probably have to re-run configure to get a correctly updated Makefile.global. We'll use the new configure variable in a follow-on patch. Per gripe from Kyotaro Horiguchi. Back-patch to all supported branches, because the follow-on patch is a portability bug fix. Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com
The MSVC build system already did this, and commit 617dc6d299c957e2784320382b3277ede01d9c63 used it in a second file. Back-patch to 9.4, like that commit. Discussion: https://postgr.es/m/CAA8=A7_1SWc3+3Z=-utQrQFOtrj_DeohRVt7diA2tZozxsyUOQ@mail.gmail.com
pgoutput evidently needs to be built without -DBUILDING_DLL. (It seems like a pretty bad idea that these makefiles need to know exactly where all the shlibs are in the tree, or maybe what's bad is putting them under src/backend/. But right now is not the time to redesign that.) Also, remove "override CPPFLAGS" in pgoutput's Makefile. I don't think that that actually has any bad consequences, but it's certainly useless in a directory that has no .h files, and it might be contributing to the failure somehow. Per buildfarm.
The MSVC build process already did so; this fixes the principal build process to match. Both processes already did likewise for src/common. This lets server builds of src/port reference postgres.exe data symbols.
Even if this is needed, it'd be configure's responsibility to set it.
The preferred method is to use "cc -shared", and this allows binaries to be rebased if required, unlike dllwrap. Backpatch to 9.0 where we have buildfarm coverage. There are still some issues with Cygwin, especially modern Cygwin, but this helps us get closer to good support. Marco Atzeri.
Apparently, they need -DBUILDING_DLL for the Assert() declarations to work correctly.