3

I recently upgraded to Mac OS X Lion and am trying to get psycopg2 working again with python 2.6. The instructions on previous sites to force Python to run in 32 bit more (seen places like here: http://favosdream.blogspot.com/2009/09/make-psycopg2-and-readline-work-in-snow.html ) aren't giving any luck. Even trying to force python to 32 bit using arch -i386 python is still giving me the error: 

symbol not found: _PQbackendPID
  Referenced from: /Library/Python/2.6/site-packages/psycopg2/_psycopg.so
  Expected in: flat namespace
mikec
  • 3,543
  • 7
  • 30
  • 34

4 Answers4

6

Recently had this issue trying to import psycopg2 (2.8.2) into a python3 (3.5.3) project. Running macOS Sierra (10.12.6), using PostgreSQL 9.6 + pgAdmin3.

TLDR: be careful when installing SQL programs & the dynamic links that installers create

From what I can tell, the required libpq dynamic library (libpq.5.dylib) that's compatible with psycopg2 (2.8.2) is libpq 5.9+ (libpq.5.9.dylib)

When postgres (or other postgres-dependent programs) are installed, they may create dynamic links in /usr/lib to the newly installed .dylib files, which may not necessarily be the ones you want.

For example, /usr/lib/libpq.5.dylib may point to ./Applications/pgAdmin3.app/Contents/Frameworks/libpq.5.dylib, which is version 5.6; the older version of the libpq dynamic library may not include some functions, like _PQsslAttribute, in this case.

The solution that worked for me:

Move /usr/local/lib up in $PATH (since usr/lib may only be writable by root), then create a dynamic link in /usr/local/lib to point to /Library/PostgreSQL/9.6/lib/libpq.5.9.dylib like this:

cd /usr/local/lib
ln -s /Library/PostgreSQL/9.6/lib/libpq.5.9.dylib ./libpq.5.dylib
mckuss
  • 61
  • 1
  • 4
  • Thnx! Using Postgres.app the only command worked for me: ```ln -s /Applications/Postgres.app/Contents/Versions/latest/lib/libpq.5.dylib ./libpq.5.dylib``` – Alex Joz Aug 13 '19 at 11:35
  • This is quite interesting. I have tried to move everything (postgred, redis etc) on my PC to docker containers, and ended up with such errors. Now, put those back through `brew` and everything is fine. – C-- Aug 15 '19 at 06:04
  • How to "move /usr/local/lib up in $PATH"? I have the same error with OS11/Apple Silicon/Postgres13/Postgres.app/Python3.8. – niels Nov 30 '20 at 20:55
3

I had this problem too on Snow Leopard/10.6.8, and just lost a half a day in the middle of a pretty intense contract. Not fun. I ended up fixing it by a) fully removing all postgres versions and rebooting, b) fully removing all my psycopg2 installs (use locate and be ruthless), c) upgrading my system python to 2.7, d) reinstalling virtualenv and pip so they pointed at the right python version, and then e) following the instructions on this page, starting with install postgres 9.1 from the dmg installer:

http://hardlifeofapo.com/psycopg2-and-postgresql-9-1-on-snow-leopard/

Ultimately it was this easy:

virtualenv your_virtual_env_name
. your_virtual_env_name/bin/activate
export ARCHFLAGS="-arch i386 -arch x86_64"
export PATH=$PATH:/Library/PostgreSQL/9.1/bin
pip install psycopg2

Good luck!

Dan Ancona
  • 162
  • 7
1

Symbol not found: _PQbackendPID Expected in: flat namespace

I have come across the same symbol error on Arm64 Mac with Big Sur.

I am using Progressapp (x86_64) and psycopg2 v2.8.4 (Arm64). Since Progressapp Arm64 version is not yet available I decided to check the linking of the libraries for psycopg2.

My solution was, first to uninstall Progressapp, then export PATH=/opt/local/lib/postgresql13/bin:$PATH point to Arm64 libpq.5.13.dylib, and finally re-install Pogressapp. So psycopg2 loads all Arm64 libraries needed.

otool -E venv/lib/python3.8/site-packages/psycopg2/_psycopg.cpython-38-darwin.so outputs:

    /opt/local/lib/postgresql13/libpq.5.dylib (compatibility version 5.0.0, current version 5.13.0)
        /opt/local/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /opt/local/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
Mahmut ARIKAN
  • 615
  • 8
  • 7
  • 1
    where did you got Arm64 libpq.5.13.dylib ? – yanik Jan 12 '21 at 05:17
  • 1
    Hi Yanik. Arm64 libpq.5.13.dylib came with the (macports) port install postgresql13 @13.1_0 . – Mahmut ARIKAN Jan 12 '21 at 11:51
  • How do I execute the export command? Could you please provide a full snippet for that? I am new to mac. Thank you! – BastianW Jan 21 '21 at 20:45
  • Hi BastionW, Open an terminal and type: export PATH=/opt/local/lib/postgresql13/bin:$PATH or preferably add it to your .bashrc or .zshrc so that it is automatically loaded everytime you open a new terminal. – Mahmut ARIKAN Jan 22 '21 at 22:08
1

Did you try arch -i386 python2.6 if you are using the Apple-supplied Python 2.6 in /usr/bin/python2.6? But if you are still running a 32-bit version of psycopg2 and the PostgreSQL client libraries, it might be a good time to install newer 64-bit or 64-bit/32-bit universal versions. MacPorts can help with that.

Ned Deily
  • 83,389
  • 16
  • 128
  • 151
  • so here's an update: doing arch -i386 python works, I am able to import psycopg2 fine. However, when trying to run my django server by typing 'arch -i386 python manage.py runserver' it fails on the import. Seems it is not taking the arch argument when trying to start django – mikec Aug 09 '11 at 17:19
  • It may be that another Python subprocess is being started and defaults to 64-bit. If you are using the Apple-supplied Python 2.6, you may be able to work around the problem by setting the special Apple environment variables `export VERSIONER_PYTHON_VERSION=2.6` and `export VERSIONER_PYTHON_PREFER_32_BIT=yes` if you use `/usr/bin/python`. See the Apple man page for python (`man python`). But you are probably better off longterm by upgrading. – Ned Deily Aug 09 '11 at 17:46
  • Oh, darn! If you did follow the other person's advice in your other question and wiped out `/usr/bin/python` by overwriting it with a symlink, the `export` suggestions above probably will not work. I believe that magic is handled by Apple's special `/usr/bin/python` program. – Ned Deily Aug 09 '11 at 17:56