rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/port/Makefile

144 lines
4.9 KiB
Makefile
Raw Normal View History

Move libc replacement files from src/backend/port to src/port.
2002-07-18 06:13:59 +02:00
#-------------------------------------------------------------------------
#
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
# Makefile
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# Makefile for src/port
Move libc replacement files from src/backend/port to src/port.
2002-07-18 06:13:59 +02:00
#
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# These files are used by the Postgres backend, and also by frontend
# programs. Primarily, they are meant to provide portability on systems
# with broken/missing library files.
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
#
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# This makefile generates three outputs:
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
#
# libpgport.a - contains object files with FRONTEND defined,
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# for use by client applications
#
# libpgport_shlib.a - contains object files with FRONTEND defined,
# built suitably for use in shared libraries; for use
Build src/common files as a library with -fPIC. Build a third version of libpgcommon.a, with -fPIC and -DFRONTEND, as commit ea53100d5 did for src/port. Use that in libpq to avoid symlinking+rebuilding source files retail. Also adjust ecpg to use the new src/port and src/common libraries. Arrange to install these libraries, too, to simplify out-of-tree builds of shared libraries that need any of these modules. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us Discussion: https://postgr.es/m/E1g5Y8r-0006vs-QA@gemulon.postgresql.org
2018-09-28 20:28:19 +02:00
# by frontend libraries
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
#
# libpgport_srv.a - contains object files without FRONTEND defined,
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# for use only by the backend
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
#
Move a couple of initdb's subroutines into src/port/. mkdir_p and check_data_dir will be useful in CREATE TABLESPACE, since we have agreed that that command should handle subdirectory creation just like initdb creates the PGDATA directory. Push them into src/port/ so that they are available to both initdb and the backend. Rename to pg_mkdir_p and pg_check_dir, just to be on the safe side. Add FreeBSD's copyright notice to pgmkdirp.c, since that's where the code came from originally (this really should have been in initdb.c). Very marginal code/comment cleanup.
2010-12-11 01:42:44 +01:00
# LIBOBJS is set by configure (via Makefile.global) to be the list of object
# files that are conditionally needed as determined by configure's probing.
Change initdb and CREATE DATABASE to actively reject attempts to create databases with encodings that are incompatible with the server's LC_CTYPE locale, when we can determine that (which we can on most modern platforms, I believe). C/POSIX locale is compatible with all encodings, of course, so there is still some usefulness to CREATE DATABASE's ENCODING option, but this will insulate us against all sorts of recurring complaints caused by mismatched settings. I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge into a new src/port/ file so it could be shared by CREATE DATABASE.
2007-09-29 00:25:49 +02:00
# OBJS adds additional object files that are always compiled.
#
Move libc replacement files from src/backend/port to src/port.
2002-07-18 06:13:59 +02:00
# IDENTIFICATION
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
# src/port/Makefile
Move libc replacement files from src/backend/port to src/port.
2002-07-18 06:13:59 +02:00
#
#-------------------------------------------------------------------------
subdir = src/port
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
override CPPFLAGS := -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS)
Add thread library to libpgport creation.
2004-05-30 16:07:47 +02:00
LIBS += $(PTHREAD_LIBS)
Fix for vpath builds.
2004-05-22 04:15:08 +02:00
Use Intel SSE 4.2 CRC instructions where available. Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 16:05:03 +02:00
OBJS = $(LIBOBJS) $(PG_CRC32C_OBJS) chklocale.o erand48.o inet_net_ntop.o \
Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT. Test for the compiler builtins __builtin_clz, __builtin_ctz, and __builtin_popcount, and make use of these in preference to handwritten C code if they're available. Create src/port infrastructure for "leftmost one", "rightmost one", and "popcount" so as to centralize these decisions. On x86_64, __builtin_popcount generally won't make use of the POPCNT opcode because that's not universally supported yet. Provide code that checks CPUID and then calls POPCNT via asm() if available. This requires indirecting through a function pointer, which is an annoying amount of overhead for a one-instruction operation, but it's probably not worth working harder than this for our current use-cases. I'm not sure we've found all the existing places that could profit from this new infrastructure; but we at least touched all the ones that used copied-and-pasted versions of the bitmapset.c code, and got rid of multiple copies of the associated constant arrays. While at it, replace c-compiler.m4's one-per-builtin-function macros with a single one that can handle all the cases we need to worry about so far. Also, because I'm paranoid, make those checks into AC_LINK checks rather than just AC_COMPILE; the former coding failed to verify that libgcc has support for the builtin, in cases where it's not inline code. David Rowley, Thomas Munro, Alvaro Herrera, Tom Lane Discussion: https://postgr.es/m/CAKJS1f9WTAGG1tPeJnD18hiQW5gAk59fQ6WK-vfdAKEHyRg2RA@mail.gmail.com
2019-02-16 05:22:27 +01:00
noblock.o path.o pg_bitutils.o pgcheckdir.o pgmkdirp.o pgsleep.o \
Remove configure switch --disable-strong-random This removes a portion of infrastructure introduced by fe0a0b5 to allow compilation of Postgres in environments where no strong random source is available, meaning that there is no linking to OpenSSL and no /dev/urandom (Windows having its own CryptoAPI). No systems shipped this century lack /dev/urandom, and the buildfarm is actually not testing this switch at all, so just remove it. This simplifies particularly some backend code which included a fallback implementation using shared memory, and removes a set of alternate regression output files from pgcrypto. Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/20181230063219.GG608@paquier.xyz
2019-01-01 12:05:51 +01:00
pg_strong_random.o pgstrcasecmp.o pgstrsignal.o pqsignal.o \
Always use our own versions of *printf(). We've spent an awful lot of effort over the years in coping with platform-specific vagaries of the *printf family of functions. Let's just forget all that mess and standardize on always using src/port/snprintf.c. This gets rid of a lot of configure logic, and it will allow a saner approach to dealing with %m (though actually changing that is left for a follow-on patch). Preliminary performance testing suggests that as it stands, snprintf.c is faster than the native printf functions for some tasks on some platforms, and slower for other cases. A pending patch will improve that, though cases with floating-point conversions will doubtless remain slower unless we want to put a *lot* of effort into that. Still, we've not observed that *printf is really a performance bottleneck for most workloads, so I doubt this matters much. Patch by me, reviewed by Michael Paquier Discussion: https://postgr.es/m/2975.1526862605@sss.pgh.pa.us
2018-09-26 19:13:57 +02:00
qsort.o qsort_arg.o quotes.o snprintf.o sprompt.o strerror.o \
tar.o thread.o
Move a couple of initdb's subroutines into src/port/. mkdir_p and check_data_dir will be useful in CREATE TABLESPACE, since we have agreed that that command should handle subdirectory creation just like initdb creates the PGDATA directory. Push them into src/port/ so that they are available to both initdb and the backend. Rename to pg_mkdir_p and pg_check_dir, just to be on the safe side. Add FreeBSD's copyright notice to pgmkdirp.c, since that's where the code came from originally (this really should have been in initdb.c). Very marginal code/comment cleanup.
2010-12-11 01:42:44 +01:00
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# libpgport.a, libpgport_shlib.a, and libpgport_srv.a contain the same files
# foo.o, foo_shlib.o, and foo_srv.o are all built from foo.c
OBJS_SHLIB = $(OBJS:%.o=%_shlib.o)
Change initdb and CREATE DATABASE to actively reject attempts to create databases with encodings that are incompatible with the server's LC_CTYPE locale, when we can determine that (which we can on most modern platforms, I believe). C/POSIX locale is compatible with all encodings, of course, so there is still some usefulness to CREATE DATABASE's ENCODING option, but this will insulate us against all sorts of recurring complaints caused by mismatched settings. I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge into a new src/port/ file so it could be shared by CREATE DATABASE.
2007-09-29 00:25:49 +02:00
OBJS_SRV = $(OBJS:%.o=%_srv.o)
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
all: libpgport.a libpgport_shlib.a libpgport_srv.a
Move libc replacement files from src/backend/port to src/port.
2002-07-18 06:13:59 +02:00
> Please find enclose a submission to fix these problems. > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO
2004-08-20 22:13:10 +02:00
# libpgport is needed by some contrib
Allow installation into directories containing spaces in the name.
2005-12-09 22:19:36 +01:00
install: all installdirs
$(INSTALL_STLIB) libpgport.a '$(DESTDIR)$(libdir)/libpgport.a'
Build src/common files as a library with -fPIC. Build a third version of libpgcommon.a, with -fPIC and -DFRONTEND, as commit ea53100d5 did for src/port. Use that in libpq to avoid symlinking+rebuilding source files retail. Also adjust ecpg to use the new src/port and src/common libraries. Arrange to install these libraries, too, to simplify out-of-tree builds of shared libraries that need any of these modules. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us Discussion: https://postgr.es/m/E1g5Y8r-0006vs-QA@gemulon.postgresql.org
2018-09-28 20:28:19 +02:00
$(INSTALL_STLIB) libpgport_shlib.a '$(DESTDIR)$(libdir)/libpgport_shlib.a'
Allow installation into directories containing spaces in the name.
2005-12-09 22:19:36 +01:00
installdirs:
Update of install-sh, mkinstalldirs, and associated configury Update install-sh to that from Autoconf 2.63, plus our Darwin-specific changes (which I simplified a bit). install-sh is now able to install multiple files in one run, so we could simplify our makefiles sometime. install-sh also now has a -d option to create directories, so we don't need mkinstalldirs anymore. Use AC_PROG_MKDIR_P in configure.in, so we can use mkdir -p when available instead of install-sh -d. For consistency with the rest of the world, the corresponding make variable has been renamed from $(mkinstalldirs) to $(MKDIR_P).
2009-08-27 00:24:44 +02:00
$(MKDIR_P) '$(DESTDIR)$(libdir)'
> Please find enclose a submission to fix these problems. > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO
2004-08-20 22:13:10 +02:00
uninstall:
Allow installation into directories containing spaces in the name.
2005-12-09 22:19:36 +01:00
rm -f '$(DESTDIR)$(libdir)/libpgport.a'
Build src/common files as a library with -fPIC. Build a third version of libpgcommon.a, with -fPIC and -DFRONTEND, as commit ea53100d5 did for src/port. Use that in libpq to avoid symlinking+rebuilding source files retail. Also adjust ecpg to use the new src/port and src/common libraries. Arrange to install these libraries, too, to simplify out-of-tree builds of shared libraries that need any of these modules. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us Discussion: https://postgr.es/m/E1g5Y8r-0006vs-QA@gemulon.postgresql.org
2018-09-28 20:28:19 +02:00
rm -f '$(DESTDIR)$(libdir)/libpgport_shlib.a'
> Please find enclose a submission to fix these problems. > > The patch adds missing the "libpgport.a" file to the installation under > "install-all-headers". It is needed by some contribs. I install the > library in "pkglibdir", but I was wondering whether it should be "libdir"? > I was wondering also whether it would make sense to have a "libpgport.so"? > > It fixes various macros which are used by contrib makefiles, especially > libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are > needed to > > It adds the ability to test and use PGXS with contribs, with "make > USE_PGXS=1". Without the macro, this is exactly as before, there should be > no difference, esp. wrt the vpath feature that seemed broken by previous > submission. So it should not harm anybody, and it is useful at least to me. > > It fixes some inconsistencies in various contrib makefiles > (useless override, ":=" instead of "="). Fabien COELHO
2004-08-20 22:13:10 +02:00
Change initdb and CREATE DATABASE to actively reject attempts to create databases with encodings that are incompatible with the server's LC_CTYPE locale, when we can determine that (which we can on most modern platforms, I believe). C/POSIX locale is compatible with all encodings, of course, so there is still some usefulness to CREATE DATABASE's ENCODING option, but this will insulate us against all sorts of recurring complaints caused by mismatched settings. I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge into a new src/port/ file so it could be shared by CREATE DATABASE.
2007-09-29 00:25:49 +02:00
libpgport.a: $(OBJS)
Unlink static libraries before rebuilding them. When the library already exists in the build directory, "ar" preserves members not named on its command line. This mattered when, for example, a "configure" rerun dropped a file from $(LIBOBJS). libpgport carried the obsolete member until "make clean". Back-patch to 9.0 (all supported versions).
2015-03-01 19:05:23 +01:00
rm -f $@
Use AROPT, not hard-coded flags.
2003-10-24 22:31:43 +02:00
$(AR) $(AROPT) $@ $^
Assemble portability modules into libpgport library. Some makefile simplifications.
2002-07-27 22:10:05 +02:00
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# thread.o and thread_shlib.o need PTHREAD_CFLAGS (but thread_srv.o does not)
Simplify makefile rule Instead of writing out the .c -> .o rule, use the default one, so that dependency tracking can be used.
2012-04-29 19:59:12 +02:00
thread.o: CFLAGS+=$(PTHREAD_CFLAGS)
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
thread_shlib.o: CFLAGS+=$(PTHREAD_CFLAGS)
Add thread.c for libpq threading, and hook it into libpq/configure.
2003-06-14 16:35:42 +02:00
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# all versions of pg_crc32c_sse42.o need CFLAGS_SSE42
Use Intel SSE 4.2 CRC instructions where available. Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 16:05:03 +02:00
pg_crc32c_sse42.o: CFLAGS+=$(CFLAGS_SSE42)
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
pg_crc32c_sse42_shlib.o: CFLAGS+=$(CFLAGS_SSE42)
Use Intel SSE 4.2 CRC instructions where available. Modern x86 and x86-64 processors with SSE 4.2 support have special instructions, crc32b and crc32q, for calculating CRC-32C. They greatly speed up CRC calculation. Whether the instructions can be used or not depends on the compiler and the target architecture. If generation of SSE 4.2 instructions is allowed for the target (-msse4.2 flag on gcc and clang), use them. If they are not allowed by default, but the compiler supports the -msse4.2 flag to enable them, compile just the CRC-32C function with -msse4.2 flag, and check at runtime whether the processor we're running on supports it. If it doesn't, fall back to the slicing-by-8 algorithm. (With the common defaults on current operating systems, the runtime-check variant is what you get in practice.) Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 16:05:03 +02:00
pg_crc32c_sse42_srv.o: CFLAGS+=$(CFLAGS_SSE42)
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
# all versions of pg_crc32c_armv8.o need CFLAGS_ARMV8_CRC32C
Use ARMv8 CRC instructions where available. ARMv8 introduced special CPU instructions for calculating CRC-32C. Use them, when available, for speed. Like with the similar Intel CRC instructions, several factors affect whether the instructions can be used. The compiler intrinsics for them must be supported by the compiler, and the instructions must be supported by the target architecture. If the compilation target architecture does not support the instructions, but adding "-march=armv8-a+crc" makes them available, then we compile the code with a runtime check to determine if the host we're running on supports them or not. For the runtime check, use glibc getauxval() function. Unfortunately, that's not very portable, but I couldn't find any more portable way to do it. If getauxval() is not available, the CRC instructions will still be used if the target architecture supports them without any additional compiler flags, but the runtime check will not be available. Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres Freund, Thomas Munro. Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 11:22:45 +02:00
pg_crc32c_armv8.o: CFLAGS+=$(CFLAGS_ARMV8_CRC32C)
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
pg_crc32c_armv8_shlib.o: CFLAGS+=$(CFLAGS_ARMV8_CRC32C)
Use ARMv8 CRC instructions where available. ARMv8 introduced special CPU instructions for calculating CRC-32C. Use them, when available, for speed. Like with the similar Intel CRC instructions, several factors affect whether the instructions can be used. The compiler intrinsics for them must be supported by the compiler, and the instructions must be supported by the target architecture. If the compilation target architecture does not support the instructions, but adding "-march=armv8-a+crc" makes them available, then we compile the code with a runtime check to determine if the host we're running on supports them or not. For the runtime check, use glibc getauxval() function. Unfortunately, that's not very portable, but I couldn't find any more portable way to do it. If getauxval() is not available, the CRC instructions will still be used if the target architecture supports them without any additional compiler flags, but the runtime check will not be available. Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres Freund, Thomas Munro. Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 11:22:45 +02:00
pg_crc32c_armv8_srv.o: CFLAGS+=$(CFLAGS_ARMV8_CRC32C)
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
#
# Shared library versions of object files
#
libpgport_shlib.a: $(OBJS_SHLIB)
rm -f $@
$(AR) $(AROPT) $@ $^
# Because this uses its own compilation rule, it doesn't use the
# dependency tracking logic from Makefile.global. To make sure that
# dependency tracking works anyway for the *_shlib.o files, depend on
# their *.o siblings as well, which do have proper dependencies. It's
# a hack that might fail someday if there is a *_shlib.o without a
# corresponding *.o, but there seems little reason for that.
%_shlib.o: %.c %.o
$(CC) $(CFLAGS) $(CFLAGS_SL) $(CPPFLAGS) -c $< -o $@
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
#
# Server versions of object files
#
Change initdb and CREATE DATABASE to actively reject attempts to create databases with encodings that are incompatible with the server's LC_CTYPE locale, when we can determine that (which we can on most modern platforms, I believe). C/POSIX locale is compatible with all encodings, of course, so there is still some usefulness to CREATE DATABASE's ENCODING option, but this will insulate us against all sorts of recurring complaints caused by mismatched settings. I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge into a new src/port/ file so it could be shared by CREATE DATABASE.
2007-09-29 00:25:49 +02:00
libpgport_srv.a: $(OBJS_SRV)
Unlink static libraries before rebuilding them. When the library already exists in the build directory, "ar" preserves members not named on its command line. This mattered when, for example, a "configure" rerun dropped a file from $(LIBOBJS). libpgport carried the obsolete member until "make clean". Back-patch to 9.0 (all supported versions).
2015-03-01 19:05:23 +01:00
rm -f $@
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
$(AR) $(AROPT) $@ $^
Fix dependency tracking for src/port/%_srv.o files Because they use their own compilation rule, they don't use the dependency tracking logic from Makefile.global. To make sure that dependency tracking works anyway for the *_srv.o files, depend on their *.o siblings as well, which do have proper dependencies. It's a hack that might fail someday if there is a *_srv.o without a corresponding *.o, but it works for now (and those would probably go into src/backend/port/ anyway).
2012-05-08 19:08:53 +02:00
# Because this uses its own compilation rule, it doesn't use the
# dependency tracking logic from Makefile.global. To make sure that
# dependency tracking works anyway for the *_srv.o files, depend on
# their *.o siblings as well, which do have proper dependencies. It's
# a hack that might fail someday if there is a *_srv.o without a
# corresponding *.o, but it works for now (and those would probably go
# into src/backend/port/ anyway).
%_srv.o: %.c %.o
Make libpgport be front-end only and make libpgport_srv be a backend library that uses palloc, ereport, etc. This simplifies the makefiles for client applications.
2004-10-04 15:43:59 +02:00
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@
Put path configuration information into a .h file instead of cluttering several different module Makefiles with it. Also, do any adjustment of installation paths during configure, rather than every time Makefile.global is read.
2004-05-21 22:56:50 +02:00
# Dependency is to ensure that path changes propagate
Change initdb and CREATE DATABASE to actively reject attempts to create databases with encodings that are incompatible with the server's LC_CTYPE locale, when we can determine that (which we can on most modern platforms, I believe). C/POSIX locale is compatible with all encodings, of course, so there is still some usefulness to CREATE DATABASE's ENCODING option, but this will insulate us against all sorts of recurring complaints caused by mismatched settings. I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge into a new src/port/ file so it could be shared by CREATE DATABASE.
2007-09-29 00:25:49 +02:00
path.o: path.c pg_config_paths.h
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
path_shlib.o: path.c pg_config_paths.h
Change initdb and CREATE DATABASE to actively reject attempts to create databases with encodings that are incompatible with the server's LC_CTYPE locale, when we can determine that (which we can on most modern platforms, I believe). C/POSIX locale is compatible with all encodings, of course, so there is still some usefulness to CREATE DATABASE's ENCODING option, but this will insulate us against all sorts of recurring complaints caused by mismatched settings. I moved initdb's existing LC_CTYPE-to-encoding mapping knowledge into a new src/port/ file so it could be shared by CREATE DATABASE.
2007-09-29 00:25:49 +02:00
path_srv.o: path.c pg_config_paths.h
Add comment about the use of pg_config_paths.h.
2006-06-26 20:40:50 +02:00
# We create a separate file rather than put these in pg_config.h
# because many of these values come from makefiles and are not
# available to configure.
Put path configuration information into a .h file instead of cluttering several different module Makefiles with it. Also, do any adjustment of installation paths during configure, rather than every time Makefile.global is read.
2004-05-21 22:56:50 +02:00
pg_config_paths.h: $(top_builddir)/src/Makefile.global
echo "#define PGBINDIR \"$(bindir)\"" >$@
echo "#define PGSHAREDIR \"$(datadir)\"" >>$@
echo "#define SYSCONFDIR \"$(sysconfdir)\"" >>$@
echo "#define INCLUDEDIR \"$(includedir)\"" >>$@
echo "#define PKGINCLUDEDIR \"$(pkgincludedir)\"" >>$@
Create a C version of pg_config. Andrew Dunstan
2004-08-01 08:56:39 +02:00
echo "#define INCLUDEDIRSERVER \"$(includedir_server)\"" >>$@
echo "#define LIBDIR \"$(libdir)\"" >>$@
Put path configuration information into a .h file instead of cluttering several different module Makefiles with it. Also, do any adjustment of installation paths during configure, rather than every time Makefile.global is read.
2004-05-21 22:56:50 +02:00
echo "#define PKGLIBDIR \"$(pkglibdir)\"" >>$@
Make the locale location relocatable. Adjust get_*_path functions to be limited to MAXPGPATH.
2004-05-25 03:00:30 +02:00
echo "#define LOCALEDIR \"$(localedir)\"" >>$@
Fix problems with PGXS builds against an installation tree that was relocated after installation. We can't trust the installation paths inserted into Makefile.global by configure, so instead we must get the paths from pg_config. This requires extending pg_config to support all the separately-configurable path names, but that was on TODO anyway.
2005-09-27 19:39:35 +02:00
echo "#define DOCDIR \"$(docdir)\"" >>$@
Added --htmldir option to pg_config, equivalent to the new configure option.
2008-02-18 15:51:48 +01:00
echo "#define HTMLDIR \"$(htmldir)\"" >>$@
Fix problems with PGXS builds against an installation tree that was relocated after installation. We can't trust the installation paths inserted into Makefile.global by configure, so instead we must get the paths from pg_config. This requires extending pg_config to support all the separately-configurable path names, but that was on TODO anyway.
2005-09-27 19:39:35 +02:00
echo "#define MANDIR \"$(mandir)\"" >>$@
Put path configuration information into a .h file instead of cluttering several different module Makefiles with it. Also, do any adjustment of installation paths during configure, rather than every time Makefile.global is read.
2004-05-21 22:56:50 +02:00
Assemble portability modules into libpgport library. Some makefile simplifications.
2002-07-27 22:10:05 +02:00
clean distclean maintainer-clean:
Build src/port files as a library with -fPIC, and use that in libpq. libpq and ecpg need shared-library-friendly versions of assorted src/port/ and src/common/ modules. Up to now, they got those by symlinking the individual source files and compiling them locally. That's baroque, and a pain to maintain, and it results in some amount of duplicated compile work. It might've made sense when only a couple of files were needed, but the list has grown and grown and grown :-( It makes more sense to have the originating directory build a third variant of libpgport.a/libpgcommon.a containing modules built with $(CFLAGS_SL), and just link that into the shared library. Unused files won't get linked, so the end result should be the same. This patch makes a down payment on that idea by having src/port/ build such a library and making libpq use it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Discussion: https://postgr.es/m/13022.1538003440@sss.pgh.pa.us
2018-09-27 17:23:43 +02:00
rm -f libpgport.a libpgport_shlib.a libpgport_srv.a
rm -f $(OBJS) $(OBJS_SHLIB) $(OBJS_SRV) pg_config_paths.h