Odd error when executing "runserver"

620 views
Skip to first unread message

Huuuze

unread,
Aug 28, 2008, 4:43:27 PM8/28/08
to Django users
I recently installed PostgreSQL 8.3.3 and psycopg 2 (latest from
SVN). When I attempt to start Django, I receive this error:

File "/Library/Python/2.5/site-packages/django/db/backends/
postgresql_psycopg2/base.py", line 20, in <module>
raise ImproperlyConfigured("Error loading psycopg2 module: %s" %
e)
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2
module: dlopen(/Library/Python/2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: /Users/buildfarm/pginstaller/server/staging/
osx/lib/libpq.5.dylib
Referenced from: /Library/Python/2.5/site-packages/psycopg2/
_psycopg.so
Reason: image not found

Is this an issue with Django, psycopg, or both?

Malcolm Tredinnick

unread,
Aug 28, 2008, 4:53:21 PM8/28/08
to django...@googlegroups.com

Looks like a problem with your psycopg2 package not being properly
installed, although Im not sure what the exact error message implies,
not being an OS X users (which seems to be the system you're using).

Regards,
Malcolm


James Matthews

unread,
Aug 28, 2008, 6:59:05 PM8/28/08
to django...@googlegroups.com
Did you ldconfig? Did you add the library to your LD_CONFIG?

Graham Dumpleton

unread,
Aug 28, 2008, 9:10:37 PM8/28/08
to Django users
The error 'Image not found' on MacOS X normally means that the .so
doesn't contain the object code for the architecture that the process
it is being loaded into requires.

This is normally an issue for mod_python and mod_wsgi on Leopard where
the operating system supplied Apache is compiled with 64 bit support
and so runs as 64 bit on latest hardware. What happens is that default
compilation options for Python packages only builds them as 32 bit and
thus the 64 bit architecture wouldn't be present in C extension
modules.

Since 'python' executable is not fully fat and only runs as 32 bit
even if have 64 bit CPU, that you are getting this error when using
"runserver" would indicate that you have installed pyscopg binaries
from PowerPC, or if you compiled it yourself, that you have set it up
to be 64 bit in mistaken belief that since you have 64 bit CPU that
you would want to.

You can find further details on these architecture issues at:

http://code.google.com/p/modwsgi/wiki/InstallationOnMacOSX

What you need to do is check build scripts for psycopg and ensure that
it doesn't only have '-arch x86_64' as option, when it probably also
needs to list at least '-arch i386'.

Graham

Whyneedsgoogle2know?

unread,
Sep 17, 2008, 1:02:51 AM9/17/08
to Django users


Graham Dumpleton wrote:
> On Aug 29, 6:43 am, Huuuze <huu...@orgoo.com> wrote:
> >
> > Is this an issue with Django, psycopg, or both?
>
> The error 'Image not found' on MacOS X normally means that the .so
> doesn't contain the object code for the architecture that the process
> it is being loaded into requires.
>
> This is normally an issue for mod_python and mod_wsgi on Leopard where
> the operating system supplied Apache is compiled with 64 bit support
> and so runs as 64 bit on latest hardware. What happens is that default
> compilation options for Python packages only builds them as 32 bit and
> thus the 64 bit architecture wouldn't be present in C extension
> modules.
>
> Since 'python' executable is not fully fat and only runs as 32 bit
> even if have 64 bit CPU, that you are getting this error when using
> "runserver" would indicate that you have installed pyscopg binaries
> from PowerPC, or if you compiled it yourself, that you have set it up
> to be 64 bit in mistaken belief that since you have 64 bit CPU that
> you would want to.

I encountered the same problem as described above. I compiled python
manually and also compiled psycogp2. The are both i386 packages. But
the problem still occurs:

django.core.exceptions.ImproperlyConfigured: Error loading psycopg2
module: dlopen(/usr/lib/python2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: libpq.5.dylib
Referenced from: /usr/lib/python2.5/site-packages/psycopg2/
_psycopg.so
Reason: image not found

Somebody suggested to look into it from the shell, but result is the
same:

Python 2.5.2 (r252:60911, Sep 17 2008, 06:47:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import psycopg2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/site-packages/psycopg2/__init__.py", line
60, in <module>
from _psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID
ImportError: dlopen(/usr/lib/python2.5/site-packages/psycopg2/
_psycopg.so, 2): Library not loaded: libpq.5.dylib
Referenced from: /usr/lib/python2.5/site-packages/psycopg2/
_psycopg.so
Reason: image not found

Any idea how to fix that?

> Graham

So long,
Andrej

Graham Dumpleton

unread,
Sep 17, 2008, 1:27:21 AM9/17/08
to Django users


On Sep 17, 3:02 pm, "Whyneedsgoogle2know?" <goo...@andrej-schoeke.de>
wrote:
Have you really installed Python with prefix of '/', thereby
replacing /usr/bin/python shipped with Mac OS X 10.5?

It would make our lives so much simpler if people simply used the
standard Python that comes with MacOS X 10.5 rather than trying to
install the very very latest minor patch revision. I have seen too
many people screw up their Python installations by trying to install
MacPorts Python. :-(

If installing from source, you should also at least install into /usr/
local rather than / as it looks like you may have based on the fact
that /usr/lib/python2.5 is being used.

Graham

Graham Dumpleton

unread,
Sep 17, 2008, 1:36:10 AM9/17/08
to Django users


On Sep 17, 3:02 pm, "Whyneedsgoogle2know?" <goo...@andrej-schoeke.de>
wrote:
Anyway, now that I have had my grumble. Post the output of running
file on the following:

1. 'python' executable used.

2. /usr/lib/python2.5/site-packages/psycopg2/_psycopg.so

3. libpq.5.dylib where ever it is. Use otool -L on _psycopg.so to find
out where it is coming from.

All three need to have the i386 architecture. Thus make sure you check
libpq as well.

Graham

Huuuze

unread,
Sep 17, 2008, 6:49:37 AM9/17/08
to Django users
I got it working by using Psycopg 2 Beta 7, rather than Beta 8. You
can DL it here:

http://www.initd.org/svn/psycopg/psycopg2/tags/2_0_BETA_7/

On Sep 17, 1:02 am, "Whyneedsgoogle2know?" <goo...@andrej-schoeke.de>
wrote:

Whyneedsgoogle2know?

unread,
Sep 17, 2008, 11:03:29 AM9/17/08
to Django users
> > Traceback (most recent call last):
> > � File "<stdin>", line 1, in <module>
> > � File "/usr/lib/python2.5/site-packages/psycopg2/__init__.py", line
> > 60, in <module>
> > � � from _psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID
> > ImportError: dlopen(/usr/lib/python2.5/site-packages/psycopg2/
> > _psycopg.so, 2): Library not loaded: libpq.5.dylib
> > � Referenced from: /usr/lib/python2.5/site-packages/psycopg2/
> > _psycopg.so
> > � Reason: image not found
> >
> > Any idea how to fix that?
>
> Anyway, now that I have had my grumble.

So noted.

> Post the output of running
> file on the following:
>
> 1. 'python' executable used.

andrej$ file /usr/bin/python
/usr/bin/python: Mach-O executable i386


> 2. /usr/lib/python2.5/site-packages/psycopg2/_psycopg.so

andrej$ file /usr/lib/python2.5/site-packages/psycopg2/_psycopg.so
/usr/lib/python2.5/site-packages/psycopg2/_psycopg.so: Mach-O bundle
i386

> 3. libpq.5.dylib where ever it is. Use otool -L on _psycopg.so to find
> out where it is coming from.

andrej$ file /Library/PostgreSQL/8.3/lib/libpq.5.dylib
/Library/PostgreSQL/8.3/lib/libpq.5.dylib: Mach-O universal binary
with 2 architectures
/Library/PostgreSQL/8.3/lib/libpq.5.dylib (for architecture ppc): Mach-
O dynamically linked shared library ppc
/Library/PostgreSQL/8.3/lib/libpq.5.dylib (for architecture i386):
Mach-O dynamically linked shared library i386

> All three need to have the i386 architecture. Thus make sure you check
> libpq as well.

hmmm.

> Graham

Andrej

Graham Dumpleton

unread,
Sep 17, 2008, 7:09:08 PM9/17/08
to Django users


On Sep 18, 1:03 am, "Whyneedsgoogle2know?" <goo...@andrej-schoeke.de>
wrote:
All I can suggest at this point then is to do an otool -L on /Library/
PostgreSQL/8.3/lib/libpq.5.dylib and work out what its dependants are.
For each of those run 'file' to check architectures. Repeat this
process down until you have got to the bottom and verified that all
have i386.

If _pyscopg has other dependencies, also check those as well.

Does seem a bit odd doesn't it.

Graham
Reply all
Reply to author
Forward
0 new messages