[Gdal-dev] more compile issues...

[Frank Warmerdam]

Byron Amerson wrote:
> Hello again,
> 
> Thanks Frank, that was indeed the solution to that issue.
> 
> please forgive my novice questions here - If this is not the appropriate
> forum I would appreciate redirection to the right place,  that being said
> I am going to proceed with some questions...thanks.
> 
> On a mac running os 10.3.
> 
> I have two issues.  The first concerns python.  I used fink to install
> python2.3 and numeric.  these live in the directory /sw as opposed to
> /usr/local - how can I get gdal to recognize this?  I have had no luck
> with the --with-pymoddir modifier for configure. I ended up ditching
> python - which I'd rather not do - I am trying to learn this stuff...

Byron,

Generally speaking the location information for where to find python
libraries and include files is determined by querying the python
executable itself.  If you want to point it at a particular python
instance you might be able to do something like:

   configure --with-python=/sw/bin/python

Configure then runs the python executable with various python scripts
trying to figure out where to find stuff.  The --with-pymoddir is used
to override where the output python scripts and loadable modules should
be placed ... used primarily if you don't have permission to write in
the standard location.

That said, you may be running into more esoteric issues.  In theory
the python stuff should work even without pointing configure at the
python executable if it is in your PATH.

> second then is an error message from make.  here is how my configure
> command looks(note I have many of these libs in /usr/lib and in /sw/lib
> but chose to use the stuff included with gdal):
...
> vtable for __cxxabiv1::__class_type_info
> vtable for __cxxabiv1::__si_class_type_info
> operator delete(void*)
> operator new(unsigned long)
> ___gxx_personality_v0
> operator delete[](void*)
> operator new[](unsigned long)
> ___cxa_pure_virtual
> vtable for __cxxabiv1::__vmi_class_type_info
> /usr/bin/libtool: internal link edit command failed
> make[1]: *** [libgdal.1.1.dylib] Error 1
> make: *** [check-lib] Error 2

The problem here is that gcc is being used to link instead of g++ so the
C++ libraries are not being included.  You can edit GDALmake.opt after
configuring to change LD_SHARED to "g++ -dynamiclib".  What version of GDAL
are you working with?

If it is 1.1.9 or earlier, I would suggest you download and try with a nightly
snapshot.  There has been some work recently on MacOS X support that might
make things run smoother for you.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent