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

147 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
# by libpq and other 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 \
Move pg_crc.c to src/common, and remove pg_crc_tables.h To get CRC functionality in a client program, you now need to link with libpgcommon instead of libpgport. The CRC code has nothing to do with portability, so libpgcommon is a better home. (libpgcommon didn't exist when pg_crc.c was originally moved to src/port.) Remove the possibility to get CRC functionality by just #including pg_crc_tables.h. I'm not aware of any extensions that actually did that and couldn't simply link with libpgcommon. This also moves the pg_crc.h header file from src/include/utils to src/include/common, which will require changes to any external programs that currently does #include "utils/pg_crc.h". That seems acceptable, as include/common is clearly the right home for it now, and the change needed to any such programs is trivial.
2015-02-09 10:17:56 +01:00
noblock.o path.o pgcheckdir.o pgmkdirp.o pgsleep.o \
Revert "Replace PostmasterRandom() with a stronger way of generating randomness." This reverts commit 9e083fd4683294f41544e6d0d72f6e258ff3a77c. That was a few bricks shy of a load: * Query cancel stopped working * Buildfarm member pademelon stopped working, because the box doesn't have /dev/urandom nor /dev/random. This clearly needs some more discussion, and a quite different patch, so revert for now.
2016-10-18 15:28:23 +02:00
pgstrcasecmp.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
Replace PostmasterRandom() with a stronger source, second attempt. This adds a new routine, pg_strong_random() for generating random bytes, for use in both frontend and backend. At the moment, it's only used in the backend, but the upcoming SCRAM authentication patches need strong random numbers in libpq as well. pg_strong_random() is based on, and replaces, the existing implementation in pgcrypto. It can acquire strong random numbers from a number of sources, depending on what's available: - OpenSSL RAND_bytes(), if built with OpenSSL - On Windows, the native cryptographic functions are used - /dev/urandom Unlike the current pgcrypto function, the source is chosen by configure. That makes it easier to test different implementations, and ensures that we don't accidentally fall back to a less secure implementation, if the primary source fails. All of those methods are quite reliable, it would be pretty surprising for them to fail, so we'd rather find out by failing hard. If no strong random source is available, we fall back to using erand48(), seeded from current timestamp, like PostmasterRandom() was. That isn't cryptographically secure, but allows us to still work on platforms that don't have any of the above stronger sources. Because it's not very secure, the built-in implementation is only used if explicitly requested with --disable-strong-random. This replaces the more complicated Fortuna algorithm we used to have in pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom, so it doesn't seem worth the maintenance effort to keep that. pgcrypto functions that require strong random numbers will be disabled with --disable-strong-random. Original patch by Magnus Hagander, tons of further work by Michael Paquier and me. Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 12:42:59 +01:00
ifeq ($(enable_strong_random), yes)
OBJS += pg_strong_random.o
endif
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
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
# currently we don't install libpgport_shlib.a, maybe we should?
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'
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'
> 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