On Fri, Nov 18, 2016 at 2:51 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > 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.
Nothing more will likely happen in this CF, so I have moved it to 2017-01 with the same status of "Needs Review". -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
