> 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 -~----------~----~----~----~------~----~------~--~---