Merci d'avoir ajouté le journal des erreurs, sans lequel il aurait été très difficile de trouver le problème. Beau travail.
Cette partie du journal était vraiment intéressante :
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -g -DPSYCOPG_VERSION=2.8.2 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110002 -DHAVE_LO64=1 -I/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m -I. -I/usr/local/Cellar/postgresql/11.2_1/include -I/usr/local/Cellar/postgresql/11.2_1/include/server -c psycopg/typecast.c -o build/temp.macosx-10.9-x86_64-3.7/psycopg/typecast.o
gcc -bundle -undefined dynamic_lookup -arch x86_64 -g build/temp.macosx-10.9-x86_64-3.7/psycopg/psycopgmodule.o build/temp.macosx-10.9-x86_64-3.7/psycopg/green.o build/temp.macosx-10.9-x86_64-3.7/psycopg/pqpath.o build/temp.macosx-10.9-x86_64-3.7/psycopg/utils.o build/temp.macosx-10.9-x86_64-3.7/psycopg/bytes_format.o build/temp.macosx-10.9-x86_64-3.7/psycopg/libpq_support.o build/temp.macosx-10.9-x86_64-3.7/psycopg/win32_support.o build/temp.macosx-10.9-x86_64-3.7/psycopg/solaris_support.o build/temp.macosx-10.9-x86_64-3.7/psycopg/connection_int.o build/temp.macosx-10.9-x86_64-3.7/psycopg/connection_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/cursor_int.o build/temp.macosx-10.9-x86_64-3.7/psycopg/cursor_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/column_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/replication_connection_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/replication_cursor_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/replication_message_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/diagnostics_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/error_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/conninfo_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/lobject_int.o build/temp.macosx-10.9-x86_64-3.7/psycopg/lobject_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/notify_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/xid_type.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_asis.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_binary.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_datetime.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_list.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_pboolean.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_pdecimal.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_pint.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_pfloat.o build/temp.macosx-10.9-x86_64-3.7/psycopg/adapter_qstring.o build/temp.macosx-10.9-x86_64-3.7/psycopg/microprotocols.o build/temp.macosx-10.9-x86_64-3.7/psycopg/microprotocols_proto.o build/temp.macosx-10.9-x86_64-3.7/psycopg/typecast.o -L/usr/local/lib -lpq -lssl -lcrypto -o build/lib.macosx-10.9-x86_64-3.7/psycopg2/_psycopg.cpython-37m-darwin.so
ld: library not found for -lssl
Le 2ème gcc avait une mention de ceci :
-L/usr/local/lib -lpq -lssl -lcrypto -o ...
Cela signifie que le processus de compilation recherchait une bibliothèque (-l ) qui se trouve être ssl . Voir le manuel de gcc (https://linux.die.net/man/1/gcc ). Il dit que -l est de rechercher la bibliothèque nommée bibliothèque (dans notre cas ssl ) lors de la liaison.
Quelque chose avec ssl la bibliothèque manquait.
La recherche Google a conduit à un problème signalé :https://github.com/psycopg/psycopg2/issues /492 . La réponse de Joe Kemp (https://github.com/psycopg/psycopg2/issues /492#issuecomment-278481164 ) suggère de définir une variable d'environnement comme suit :
export LDFLAGS="-L/usr/local/opt/openssl/lib"
D'autres options ont été répertoriées ici :Impossible d'installer psycopg2 avec pip dans virtualenv sur Mac OS X 10.7 .
Il semble que votre paramètre LDFLAGS ait résolu le problème.
