Hi, On 2016-11-16 19:29:41 -0500, Robert Haas wrote: > On Wed, Nov 16, 2016 at 6:56 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > On Wed, Nov 16, 2016 at 11:24 AM, Robert Haas <robertmh...@gmail.com> wrote: > >> diff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile > >> index 805db76..ddb0183 100644 > >> --- a/contrib/pgcrypto/Makefile > >> +++ b/contrib/pgcrypto/Makefile > >> @@ -1,6 +1,6 @@ > >> # contrib/pgcrypto/Makefile > >> > >> -INT_SRCS = md5.c sha1.c sha2.c internal.c internal-sha2.c blf.c > >> rijndael.c \ > >> +INT_SRCS = md5.c sha1.c internal.c internal-sha2.c blf.c rijndael.c \ > >> fortuna.c random.c pgp-mpi-internal.c imath.c > >> INT_TESTS = sha2 > > > > I would like to do so. And while Linux is happy with that, macOS is > > not, this results in linking resolution errors when compiling the > > library. > > Well, I'm running macOS and it worked for me. TBH, I don't even quite > understand how it could NOT work. What makes the symbols provided by > libpgcommon any different from any other symbols that are part of the > binary? How could one set work and the other set fail? I can > understand how there might be some problem if the backend were > dynamically linked libpgcommon, but it's not. It's doing this:
With -Wl,--as-neeeded the linker will dismiss unused symbols found in a static library. Maybe that's the difference? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
