1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgres/src/port/Makefile

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

156 lines
4.6 KiB
Makefile
Raw Normal View History

Move libc replacement files from src/backend/port to src/port.
2002-07-18 04:13:59 +00: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 13:43:59 +00: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 11:23:43 -04:00
# Makefile for src/port
Move libc replacement files from src/backend/port to src/port.
2002-07-18 04:13:59 +00: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 11:23:43 -04: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 13:43:59 +00: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 11:23:43 -04: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 13:43:59 +00: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 11:23:43 -04: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 14:28:19 -04: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 13:43:59 +00: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 11:23:43 -04: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 13:43:59 +00: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-10 19:42:44 -05: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-28 22:25:49 +00:00
# OBJS adds additional object files that are always compiled.
#
Move libc replacement files from src/backend/port to src/port.
2002-07-18 04:13:59 +00: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 04:13:59 +00: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 13:43:59 +00:00
override CPPFLAGS := -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS)
Add thread library to libpgport creation.
2004-05-30 14:07:47 +00:00
LIBS += $(PTHREAD_LIBS)
Fix for vpath builds.
2004-05-22 02:15:08 +00:00
Split all OBJS style lines in makefiles into one-line-per-entry style. When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
2019-11-05 14:41:07 -08:00
OBJS = \
$(LIBOBJS) \
$(PG_CRC32C_OBJS) \
Move bsearch_arg to src/port Until now the bsearch_arg function was used only in extended statistics code, so it was defined in that code. But we already have qsort_arg in src/port, so let's move it next to it.
2021-03-23 00:11:20 +01:00
bsearch_arg.o \
Split all OBJS style lines in makefiles into one-line-per-entry style. When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
2019-11-05 14:41:07 -08:00
chklocale.o \
inet_net_ntop.o \
noblock.o \
path.o \
pg_bitutils.o \
Provide thread-safe pg_localeconv_r(). This involves four different implementation strategies: 1. For Windows, we now require _configthreadlocale() to be available and work (commit f1da075d9a0), and the documentation says that the object returned by localeconv() is in thread-local memory. 2. For glibc, we translate to nl_langinfo_l() calls, because it offers the same information that way as an extension, and that API is thread-safe. 3. For macOS/*BSD, use localeconv_l(), which is thread-safe. 4. For everything else, use uselocale() to set the locale for the thread, and use a big ugly lock to defend against the returned object being concurrently clobbered. In practice this currently means only Solaris. The new call is used in pg_locale.c, replacing calls to setlocale() and localeconv(). Author: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CA%2BhUKGJqVe0%2BPv9dvC9dSums_PXxGo9SWcxYAMBguWJUGbWz-A%40mail.gmail.com
2025-03-27 07:52:22 +01:00
pg_localeconv_r.o \
Add support for basic NUMA awareness Add basic NUMA awareness routines, using a minimal src/port/pg_numa.c portability wrapper and an optional build dependency, enabled by --with-libnuma configure option. For now this is Linux-only, other platforms may be supported later. A built-in SQL function pg_numa_available() allows checking NUMA support, i.e. that the server was built/linked with the NUMA library. The main function introduced is pg_numa_query_pages(), which allows determining the NUMA node for individual memory pages. Internally the function uses move_pages(2) syscall, as it allows batching, and is more efficient than get_mempolicy(2). Author: Jakub Wartak <jakub.wartak@enterprisedb.com> Co-authored-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Tomas Vondra <tomas@vondra.me> Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
2025-04-07 22:51:49 +02:00
pg_numa.o \
Optimize popcount functions with ARM Neon intrinsics. This commit introduces Neon implementations of pg_popcount{32,64}, pg_popcount(), and pg_popcount_masked(). As in simd.h, we assume that all available AArch64 hardware supports Neon, so we don't need any new configure-time or runtime checks. Some compilers already emit Neon instructions for these functions, but our hand-rolled implementations for pg_popcount() and pg_popcount_masked() performed better in testing, likely due to better instruction-level parallelism. Author: "Chiranmoy.Bhattacharya@fujitsu.com" <Chiranmoy.Bhattacharya@fujitsu.com> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Discussion: https://postgr.es/m/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com
2025-03-28 14:49:35 -05:00
pg_popcount_aarch64.o \
Use __attribute__((target(...))) for AVX-512 support. Presently, we check for compiler support for the required intrinsics both with and without extra compiler flags (e.g., -mxsave), and then depending on the results of those checks, we pick which files to compile with which flags. This is tedious and complicated, and it results in unsustainable coding patterns such as separate files for each portion of code may need to be built with different compiler flags. This commit introduces support for __attribute__((target(...))) and uses it for the AVX-512 code. This simplifies both the configure-time checks and the build scripts, and it allows us to place the functions that use the intrinsics in files that we otherwise do not want to build with special CPU instructions. We are careful to avoid using __attribute__((target(...))) on compilers that do not understand it, but we still perform the configure-time checks in case the compiler allows using the intrinsics without it (e.g., MSVC). A similar change could likely be made for some of the CRC-32C code, but that is left as a future exercise. Suggested-by: Andres Freund Reviewed-by: Raghuveer Devulapalli, Andres Freund Discussion: https://postgr.es/m/20240731205254.vfpap7uxwmebqeaf%40awork3.anarazel.de
2024-11-07 13:58:43 -06:00
pg_popcount_avx512.o \
Split all OBJS style lines in makefiles into one-line-per-entry style. When maintaining or merging patches, one of the most common sources for conflicts are the list of objects in makefiles. Especially when the split across lines has been changed on both sides, which is somewhat common due to attempting to stay below 80 columns, those conflicts are unnecessarily laborious to resolve. By splitting, and alphabetically sorting, OBJS style lines into one object per line, conflicts should be less frequent, and easier to resolve when they still occur. Author: Andres Freund Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de
2019-11-05 14:41:07 -08:00
pg_strong_random.o \
pgcheckdir.o \
pgmkdirp.o \
pgsleep.o \
pgstrcasecmp.o \
pgstrsignal.o \
pqsignal.o \
qsort.o \
qsort_arg.o \
quotes.o \
snprintf.o \
strerror.o \
More use of getpwuid_r() directly Remove src/port/user.c, call getpwuid_r() directly. This reduces some complexity and allows better control of the error behavior. For example, the old code would in some circumstances silently truncate the result string, or produce error message strings that the caller wouldn't use. src/port/user.c used to be called src/port/thread.c and contained various portability complications to support thread-safety. These are all obsolete, and all but the user-lookup functions have already been removed. This patch completes this by also removing the user-lookup functions. Also convert src/backend/libpq/auth.c to use getpwuid_r() for thread-safety. Originally, I tried to be overly correct by using sysconf(_SC_GETPW_R_SIZE_MAX) to get the buffer size for getpwuid_r(), but that doesn't work on FreeBSD. All the OS where I could find the source code internally use 1024 as the suggested buffer size, so I just ended up hardcoding that. The previous code used BUFSIZ, which is an unrelated constant from stdio.h, so its use seemed inappropriate. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://www.postgresql.org/message-id/flat/5f293da9-ceb4-4937-8e52-82c25db8e4d3%40eisentraut.org
2024-09-02 08:16:25 +02:00
tar.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-10 19:42:44 -05: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 11:23:43 -04: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-28 22:25:49 +00: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 13:43:59 +00: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 11:23:43 -04:00
all: libpgport.a libpgport_shlib.a libpgport_srv.a
Move libc replacement files from src/backend/port to src/port.
2002-07-18 04:13:59 +00: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 20:13:10 +00:00
# libpgport is needed by some contrib
Allow installation into directories containing spaces in the name.
2005-12-09 21:19:36 +00: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 14:28:19 -04:00
$(INSTALL_STLIB) libpgport_shlib.a '$(DESTDIR)$(libdir)/libpgport_shlib.a'
Allow installation into directories containing spaces in the name.
2005-12-09 21:19:36 +00: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-26 22:24:44 +00: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 20:13:10 +00:00
uninstall:
Allow installation into directories containing spaces in the name.
2005-12-09 21:19:36 +00: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 14:28:19 -04: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 20:13:10 +00: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-28 22:25:49 +00: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 13:05:23 -05:00
rm -f $@
Use AROPT, not hard-coded flags.
2003-10-24 20:31:43 +00:00
$(AR) $(AROPT) $@ $^
Assemble portability modules into libpgport library. Some makefile simplifications.
2002-07-27 20:10:05 +00:00
autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C Until now we emitted the cflags to build the CRC objects into architecture specific variables. That doesn't make a whole lot of sense to me - we're never going to target x86 and arm at the same time, so they don't need to be separate variables. It might be better to instead continue to have CFLAGS_SSE42 / CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS / PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it seems unlikely that we'd need other sets of CRC specific flags for those two architectures at the same time. This simplifies the upcoming meson PGXS compatibility. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
2022-12-01 18:46:55 -08:00
# all versions of pg_crc32c_armv8.o need CFLAGS_CRC
pg_crc32c_armv8.o: CFLAGS+=$(CFLAGS_CRC)
pg_crc32c_armv8_shlib.o: CFLAGS+=$(CFLAGS_CRC)
pg_crc32c_armv8_srv.o: CFLAGS+=$(CFLAGS_CRC)
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 12:22:45 +03: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 11:23:43 -04: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 13:43:59 +00: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-28 22:25:49 +00: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 13:05:23 -05: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 13:43:59 +00: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 20:08:53 +03: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 13:43:59 +00: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 20:56:50 +00: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-28 22:25:49 +00: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 11:23:43 -04: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-28 22:25:49 +00:00
path_srv.o: path.c pg_config_paths.h
Add comment about the use of pg_config_paths.h.
2006-06-26 18:40:50 +00: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 20:56:50 +00: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 06:56:39 +00: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 20:56:50 +00:00
echo "#define PKGLIBDIR \"$(pkglibdir)\"" >>$@
Make the locale location relocatable. Adjust get_*_path functions to be limited to MAXPGPATH.
2004-05-25 01:00:30 +00: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 17:39:35 +00:00
echo "#define DOCDIR \"$(docdir)\"" >>$@
Added --htmldir option to pg_config, equivalent to the new configure option.
2008-02-18 14:51:48 +00: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 17:39:35 +00: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 20:56:50 +00:00
Remove distprep A PostgreSQL release tarball contains a number of prebuilt files, in particular files produced by bison, flex, perl, and well as html and man documentation. We have done this consistent with established practice at the time to not require these tools for building from a tarball. Some of these tools were hard to get, or get the right version of, from time to time, and shipping the prebuilt output was a convenience to users. Now this has at least two problems: One, we have to make the build system(s) work in two modes: Building from a git checkout and building from a tarball. This is pretty complicated, but it works so far for autoconf/make. It does not currently work for meson; you can currently only build with meson from a git checkout. Making meson builds work from a tarball seems very difficult or impossible. One particular problem is that since meson requires a separate build directory, we cannot make the build update files like gram.h in the source tree. So if you were to build from a tarball and update gram.y, you will have a gram.h in the source tree and one in the build tree, but the way things work is that the compiler will always use the one in the source tree. So you cannot, for example, make any gram.y changes when building from a tarball. This seems impossible to fix in a non-horrible way. Second, there is increased interest nowadays in precisely tracking the origin of software. We can reasonably track contributions into the git tree, and users can reasonably track the path from a tarball to packages and downloads and installs. But what happens between the git tree and the tarball is obscure and in some cases non-reproducible. The solution for both of these issues is to get rid of the step that adds prebuilt files to the tarball. The tarball now only contains what is in the git tree (*). Getting the additional build dependencies is no longer a problem nowadays, and the complications to keep these dual build modes working are significant. And of course we want to get the meson build system working universally. This commit removes the make distprep target altogether. The make dist target continues to do its job, it just doesn't call distprep anymore. (*) - The tarball also contains the INSTALL file that is built at make dist time, but not by distprep. This is unchanged for now. The make maintainer-clean target, whose job it is to remove the prebuilt files in addition to what make distclean does, is now just an alias to make distprep. (In practice, it is probably obsolete given that git clean is available.) The following programs are now hard build requirements in configure (they were already required by meson.build): - bison - flex - perl Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2023-11-06 14:51:52 +01:00
clean distclean:
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 11:23:43 -04:00
rm -f libpgport.a libpgport_shlib.a libpgport_srv.a
rm -f $(OBJS) $(OBJS_SHLIB) $(OBJS_SRV) pg_config_paths.h
Reference in New Issue Copy Permalink