> On OS X, using MacPorts, ctypes doesn't look in /opt/local/lib unless
> you set LD_LIBRARY_PATH. On Ubuntu Feisty, the gdal package uses a
> weird naming convention and isn't found. Is it possible to specify
> these library locations in settings.py or somewhere?

There are no explicit settings for the location of the library --
however that is a good idea, and I'll look into implementing it.  I
usually set the LD_LIBRARY_PATH in circumstances where the library is
in a nonstandard location, so this strategy should work on Ubuntu as
well.

An interim solution would be to hard-code the library location by
changing the variable `lib_name` in django/contrib/gis/geos/libgeos.py
(similarly, GDAL's library name is in gdal/libgdal.py).

> Also, on both OS X and Ubuntu, I get symbol not found errors for
> GEOSCoordSeq_getOrdinate when trying to import the geos tests (see
> below).

You are using GEOS 2.2.x, and GeoDjango requires GEOS 3.0 and above.
I know this because there's an improper forward function declaration
for GEOSCoordSeq_getOrdinate in the 2.2.x versions, and the routine
does not get exposed in the shared library.  I'm not sure if there are
binary packages available on Linux and/or OSX for 3.0 --  your best
bet for these platforms is to compile GEOS from source.  For maximum
compatibility please follow the installation instructions on the trac
wiki:
http://code.djangoproject.com/wiki/GeoDjangoInstall

I have a hunch that compiling GEOS and GDAL from source and installing
in /usr/local may eliminate the need for modifying the source files as
discussed above.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to