[Gdal-dev] Re: continued build problems..

[Byron Amerson]

Frank,

Wanted to write and say thanks for all of your time.  I eventually
compiled without python, alas (after discovering some egregious errors I
had made - I needed to reinstall some of my os!!).  I snooped into the
GDALmake.opt and attempted to understand it, but to no avail.  It's simple
ignorance, with no reference I was in the dark.  I tried again with a snapshot
from last nite but no luck - the same errors as before.

Thanks again.

Byron Amerson
MS student
University of Washington
Department of Earth and Space Sciences

On Fri, 7 Nov 2003, Byron Amerson wrote:

> Once again, thank you Frank.  I have been follwing your suggestions and
> learning quite a bit which is great.
>
> None the less gdal refuse to build on my mac.  It can't seem to find
> Numeric for one thing -
>
> Using a nightly snapshot from a few days ago, here is my config command:
>
> sudo ./configure --with-local=/usr/local/include/python2.3/Numeric
> --with-libz=internal --with-png=internal --with-libtiff=internal
> --with-geotiff=internal --with-jpeg=internal --with-gif=internal
> --with-pg=/usr/local/pgsql/bin/pg_config
>
> and the last few lines of the resulting output:
>
> checking where .py files should go...
> /usr/local/lib/python2.3/site-packages
> checking for python headers... found
> checking definitions from Python makefile... done
> checking for NumPy include files... missing
> checking if local/include already standard... no, everything is ok
> configure: creating ./config.status
> config.status: creating GDALmake.opt
> config.status: creating port/cpl_config.
>
> below is the output from make:
>
> g++ -Wl,-bind_at_load  -o .libs/_gdalmodule.so -bundle  .libs/gdal_wrap.o
> .libs/numpydataset.o .libs/gdalnumeric.o  -L/usr/local/pgsql/lib
> -L/usr/local/include/python2.3/Numeric/lib ../.libs/libgdal.dylib -lm -ldl
> -lpq -L/usr/local/src/gdal/gdal-cvs-031104/.libs
> ld: warning -L: directory name (/usr/local/include/python2.3/Numeric/lib)
> does not exist
> ld: Undefined symbols:
> _PyArg_Parse
> _PyArg_ParseTuple
> _PyDict_New
> _PyDict_Next
> _PyDict_SetItem
> _PyDict_Type
> _PyErr_Clear
> _PyErr_SetString
> _PyEval_CallObjectWithKeywords
> _PyExc_MemoryError
> _PyExc_NameError
> _PyExc_TypeError
> _PyExc_ValueError
> _PyFloat_AsDouble
> _PyFloat_FromDouble
> _PyInt_AsLong
> _PyInt_FromLong
> _PyInt_Type
> _PyList_New
> _PyList_SetItem
> _PyList_Size
> _PyList_Type
> _PyModule_GetDict
> _PyString_AsString
> _PyString_FromString
> _PyString_FromStringAndSize
> _PyString_Type
> _PyType_IsSubtype
> _PyType_Type
> _Py_BuildValue
> _Py_InitModule4
> __Py_NoneStruct
> make[1]: *** [_gdalmodule.la] Error 1
> make: *** [py-module] Error 2
>
> evidently --with-local=/usr/local/include/python2.3/Numeric is not the
> correct modifier as it seems that make is looking for shared libs in the
> above directory.  I was just attempting to get gdal to see where the
> Numeric headers lived.
>
> Incidentally - I completely rebuilt python2.3.2 and postgresql7.4beta5
> When I ran make for postgres it griped that libpython was not shared so it
> could not build the PLPYTHON bits.  I don't know if this (python shared
> libs) is relevant.
>
> I don't know how to proceed. It would be great to b using GRASS about
> now...
>
>
> Byron Amerson
> MS student
> University of Washington
> Department of Earth and Space Sciences
>