Re: Password identifiers, protocol aging and SCRAM protocol
От | Robert Haas |
---|---|
Тема | Re: Password identifiers, protocol aging and SCRAM protocol |
Дата | |
Msg-id | CA+TgmoaeBqkXhmuu5n1AbTyC7Lz9WPHMkOxnF_hvbqpz-Sf_sA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Password identifiers, protocol aging and SCRAM protocol (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Password identifiers, protocol aging and SCRAM protocol
|
Список | pgsql-hackers |
On Wed, Nov 16, 2016 at 6:56 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Nov 16, 2016 at 11:24 AM, Robert Haas <robertmhaas@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: gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -O2 -Wall -Werror -L../../src/port -L../../src/common -Wl,-dead_strip_dylibs -Wall -Werror access/brin/brin.o [many more .o files omitted for brevity] utils/fmgrtab.o ../../src/timezone/localtime.o ../../src/timezone/strftime.o ../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a ../../src/common/libpgcommon_srv.a -lm -o postgres As I understand it, listing the .a file on the linker command line like that is exactly equivalent to listing out each individual .o file that is part of that static library. There shouldn't be any difference in how a symbol that's provided by one of the .o files looks vs. how a symbol that's provided by one of the .a files looks. Let's test it. [rhaas pgsql]$ nm src/backend/postgres | grep -E 'GetUserIdAndContext|psprintf' 00000001003d71d0 T _GetUserIdAndContext 000000010040f160 T _psprintf So... how would the dynamic loader know that it was supposed to find the first one and fail to find the second one? More to the point, it's clear that it DOES find the second one on every platform in the buildfarm, because adminpack, dblink, pageinspect, and pgstattuple all use psprintf without the push-ups you are proposing to undertake here. pg_md5_encrypt is used by passwordcheck, and forkname_to_number is used by pageinspect and pg_prewarm. It all just works. No special magic required. > Yes we could do that for consistency with the other nix platforms. But > is that really necessary as libpgcommon already has those objects? The point is that *postgres* already has those objects. You don't need to include them twice. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Michael PaquierДата:
Сообщение: Re: Password identifiers, protocol aging and SCRAM protocol
Следующее
От: Andres FreundДата:
Сообщение: Re: Password identifiers, protocol aging and SCRAM protocol