#5469 closed defect (fixed)
make install fails on extensions
| Reported by: | tbussmann | Owned by: | strk |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 3.4.0 |
| Component: | build | Version: | master |
| Keywords: | Cc: | tbussmann |
Description
When building 3.4.0rc1 on macOS (with --prefix, if that matters) I get an error during make install:
---- Making install in extensions
for DIR in postgis postgis_tiger_geocoder postgis_raster postgis_topology postgis_sfcgal address_standardizer; do \
echo "---- Making install in ${DIR}"; \
/Library/Developer/CommandLineTools/usr/bin/make -C "${DIR}" install || exit 1; \
done
---- Making install in postgis
/bin/sh ../../config/install-sh -c -d '/Applications/Postgres.app/Contents/Versions/16/share/postgresql/extension'
/bin/sh: ../../config/install-sh: No such file or directory
make[3]: *** [installdirs] Error 127
make[2]: *** [install] Error 1
make[1]: *** [install] Error 1
This seems to be rooted in [6544f769/git] where PGXSs definition of top_builddir and top_absbuilddir were locally overwritten. In my build these end up as ../.. (cannot judge whether this makes sense or not). The make target install as provided by PGXS uses the variable MKDIR_P whose definition from Makefile.global refers to top_builddir resulting in the non-existing path ../../config/install-sh.
Not knowing why top_builddir was overwritten in the first place, one way to circumvent this problem is to persist PGXS's MKDIR_P in a simply expanded variable just after the include $(PGXS) with MKDIR_P := $(MKDIR_P) or to overwrite MKDIR_P to PostGIS's version by adding MKDIR_P = @MKDIR_P@ in the Makefile.ins. Attached a works-for-me patch that implements the latter, but I don't know if this is the correct approach to this problem.
If I read Makefile.global correctly, the same could happen to INSTALL as well, if PGXS's version is used instead of /usr/bin/install.
Attachments (1)
Change History (9)
by , 11 months ago
| Attachment: | postgis_install.patch added |
|---|
comment:1 by , 11 months ago
comment:3 by , 11 months ago
The attached patch seems harmless to me. We could actually also start using that variable rather than the hard-coded mkdir -p we currently use, but I'd not go there for now (if it ain't broke …)
The issue seems to be somewhat similar to #5264 on Alpine where also PGXS and own variable definitions conflicted.