On Thu, Nov 17, 2016 at 8:12 AM, Robert Haas <robertmh...@gmail.com> wrote: > So, the problem isn't Darwin-specific. I experimented with this on > Linux and found Linux does the same thing with libpgcommon_srv.a that > macOS does: a file in the archive that is totally unused is omitted > from the postgres binary. In Linux, however, that doesn't prevent > pgcrypto from compiling anyway. It does, however, prevent it from > working. Instead of failing at compile time with a complaint about > missing symbols, it fails at load time. I think that's because macOS > has -bundle-loader and we use it; without that, I think we'd get the > same behavior on macOS that we get on Windows.
Yes, right. I recall seeing the regression tests failing with pgcrypto when doing that. Though I did not recall if this was specific to macos or Linux when I looked again at this patch yesterday. When testing again yesterday I was able to make the tests of pgcrypto to pass, but perhaps my build was not in a clean state... > 1. Rejigger things so that we don't build libpgcommon_srv.a in the > first place, and instead add $(top_builddir)/src/common to > src/backend/Makefile's value of SUBDIRS. With appropriate adjustments > to src/common/Makefile, this should allow us to include all of the > object files on the linker command line individually instead of > building an archive library that is then used only for the postgres > binary itself anyway. Then, things wouldn't get dropped. > > 2. Just postpone committing this patch until we're ready to use the > new code in the backend someplace (or add a dummy reference to it > someplace). At the end this refactoring makes sense because it will be used in the backend with the SCRAM engine, so we could just wait for 2 instead of having some workarounds. This is dropping the ball for later and there will be already a lot of work for the SCRAM core part, though I don't think that the SHA2 refactoring will change much going forward. Option 3 would be to do things the patch does it, aka just compiling pgcrypto using the source files directly and put a comment to revert that once the APIs are used in the backend. I can guess that you don't like that. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
