opensourcemirror
/
postgresql
mirror of git://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Releases Wiki Activity
postgresql/src/makefiles/Makefile.darwin

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

13 lines
380 B
Makefile
Raw Permalink Normal View History

Move port-specific parts of with_temp_install to port makefile. Rather than define ld_library_path_ver with a big nested $(if), just put the overriding values in the makefiles for the relevant ports. Also add a variable for port makefiles to append their own stuff to with_temp_install, and use it to set LD_LIBRARY_PATH_RPATH=1 on FreeBSD which is needed to make LD_LIBRARY_PATH override DT_RPATH if DT_RUNPATH is not set (which seems to depend in unpredictable ways on the choice of compiler, at least on my system). Backpatch for the benefit of anyone doing regression tests on FreeBSD. (For other platforms there should be no functional change.)
2019-02-04 19:47:33 +01:00
# env var name to use in place of LD_LIBRARY_PATH
ld_library_path_var = DYLD_LIBRARY_PATH
In a PGXS build, expect to find the postgres executable already installed, rather than in $(top_builddir)/src/backend/postgres. Sean Chittenden
2004-12-17 04:52:49 +01:00
ifdef PGXS
Split the LDFLAGS make variable into two parts: LDFLAGS is now used for linking both executables and shared libraries, and we add on LDFLAGS_EX when linking executables or LDFLAGS_SL when linking shared libraries. This provides a significantly cleaner way of dealing with link-time switches than the former behavior. Also, make sure that the various platform-specific %.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that before. (I did not add these variables for the platforms that invoke $(LD) directly, however. It's not clear if we can do that safely, since for the most part we assume these variables use CC command-line syntax.) Per gripe from Aaron Swenson and subsequent investigation.
2010-07-05 20:54:38 +02:00
BE_DLLLIBS = -bundle_loader $(bindir)/postgres
In a PGXS build, expect to find the postgres executable already installed, rather than in $(top_builddir)/src/backend/postgres. Sean Chittenden
2004-12-17 04:52:49 +01:00
else
Split the LDFLAGS make variable into two parts: LDFLAGS is now used for linking both executables and shared libraries, and we add on LDFLAGS_EX when linking executables or LDFLAGS_SL when linking shared libraries. This provides a significantly cleaner way of dealing with link-time switches than the former behavior. Also, make sure that the various platform-specific %.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that before. (I did not add these variables for the platforms that invoke $(LD) directly, however. It's not clear if we can do that safely, since for the most part we assume these variables use CC command-line syntax.) Per gripe from Aaron Swenson and subsequent investigation.
2010-07-05 20:54:38 +02:00
BE_DLLLIBS = -bundle_loader $(top_builddir)/src/backend/postgres
In a PGXS build, expect to find the postgres executable already installed, rather than in $(top_builddir)/src/backend/postgres. Sean Chittenden
2004-12-17 04:52:49 +01:00
endif
Split the LDFLAGS make variable into two parts: LDFLAGS is now used for linking both executables and shared libraries, and we add on LDFLAGS_EX when linking executables or LDFLAGS_SL when linking shared libraries. This provides a significantly cleaner way of dealing with link-time switches than the former behavior. Also, make sure that the various platform-specific %.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that before. (I did not add these variables for the platforms that invoke $(LD) directly, however. It's not clear if we can do that safely, since for the most part we assume these variables use CC command-line syntax.) Per gripe from Aaron Swenson and subsequent investigation.
2010-07-05 20:54:38 +02:00
# Rule for building a shared library from a single .o file
Unify DLSUFFIX on Darwin macOS has traditionally used extension .dylib for shared libraries (used at build time) and .so for dynamically loaded modules (used by dlopen()). This complicates the build system a bit. Also, Meson uses .dylib for both, so it would be worth unifying this in order to be able to get equal build output. There doesn't appear to be any reason to use any particular extension for dlopened modules, since dlopen() will accept anything and PostgreSQL is well-factored to be able to deal with any extension. Other software packages that I have handy appear to be about 50/50 split on which extension they use for their plugins. So it seems possible to change this safely. Discussion: https://www.postgresql.org/message-id/flat/bcc45f78-e3c3-8fb3-7c42-5371b48b5266%40enterprisedb.com
2022-07-06 07:30:16 +02:00
%$(DLSUFFIX): %.o
Ensure link commands list *.o files before LDFLAGS. It's important for link commands to list *.o input files before -l switches for libraries, as library code may not get pulled into the link unless referenced by an earlier command-line entry. This is certainly necessary for static libraries (.a style). Apparently on some platforms it is also necessary for shared libraries, as reported by Donald Dong. We often put -l switches for within-tree libraries into LDFLAGS, meaning that link commands that list *.o files after LDFLAGS are hazardous. Most of our link commands got this right, but a few did not. In particular, places that relied on gmake's default implicit link rule failed, because that puts LDFLAGS first. Fix that by overriding the built-in rule with our own. The implicit link rules in src/makefiles/Makefile.* for single-.o-file shared libraries mostly got this wrong too, so fix them. I also changed the link rules for the backend and a couple of other places for consistency, even though they are not (currently) at risk because they aren't adding any -l switches to LDFLAGS. Arguably, the real problem here is that we're abusing LDFLAGS by putting -l switches in it and we should stop doing that. But changing that would be quite invasive, so I'm not eager to do so. Perhaps this is a candidate for back-patching, but so far it seems that problems can only be exhibited in test code we don't normally build, and at least some of the problems are new in HEAD anyway. So I'll refrain for now. Donald Dong and Tom Lane Discussion: https://postgr.es/m/CAKABAquXn-BF-vBeRZxhzvPyfMqgGuc74p8BmQZyCFDpyROBJQ@mail.gmail.com
2019-01-02 19:57:42 +01:00
$(CC) $(CFLAGS) $< $(LDFLAGS) $(LDFLAGS_SL) -bundle $(BE_DLLLIBS) -o $@