On Fri, Dec 7, 2018, at 5:26 PM, Tom Lane wrote:
> Interesting proposal, but I think it needs work.
Absolutely! I only hacked it together to the point that it worked on my laptop and illustrated the approach. :-)
> * As coded, this only fixes the problem for references to libpq, not
> any of our other shared libraries.
None of the the other shared libraries are referenced by the modified binaries:
$ for bin in tmp_install/usr/local/pgsql/bin/*; do otool -L $bin; done | grep dylib | sort -u
.../tmp_install/usr/local/pgsql/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.12.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
But I agree it would be nice to make it work in potential future cases, too.
> * It's also unpleasant that it hard-wires knowledge of libpq's version
> numbering in a place pretty far removed from anywhere that should know
> that.
Ideally it would iterate the binaries, iterate the load commands, and rewrite each.
> * Just to be annoying, this won't work at all on 32-bit OSX versions
> unless we link everything with -headerpad_max_install_names. (I know
> Apple forgot about 32-bit machines long ago, but our buildfarm hasn't.)
We can make the references relative which would dramatically decrease the sizes.
> * Speaking of not working, I don't think this "find" invocation will
> report any failure exits from install_name_tool.
If we iterate more carefully, as above, then failures should be reported and cause an abort.
> * This doesn't fix anything for executables that never get installed,
> for instance isolationtester.
>
> We could probably fix the first four problems with some more sweat,
> but I'm not seeing a plausible answer to the last one. Overwriting
> isolationtester's rpath to make "make check" work would just break
> it for "make installcheck".
Ah, sorry, I'm not super familiar yet with the build process so missed this bit. But I think executable-relative paths
willfix.
I tried using this line instead and `make check` and `make installcheck` both work for me. It's awful, I'm not super
fluentin Makefile so I'm sure it could be 100X better, and probably isn't quoted correctly, but the approach itself
works.I couldn't quickly figure out a portable way to generate a relative path from bindir to libdir which would be a
greatimprovement.
$(if $(filter $(PORTNAME),darwin),for binary in $(abs_top_builddir)/tmp_install$(bindir)/*; do for dylib in $$(otool -L
$$binary| tail +2 | awk '{ print $$1 }' | grep '$(libdir)'); do install_name_tool -change $$dylib
@executable_path/../lib/$${dylib##*/}$$binary || exit $$?; done; done)
Cheers,
Sam
