Massimo,

> i've solved the gdal problem using a "non framework" installation,
> ./configure --prefix=/usr/local --without-python

Interesting, i didn't know that gdal did have a 'framework' installation
option. Most of the other libraries seem to (e.g. OSG) but in the makefiles
i've seen from Pete and Nino, gdal has been just a simple library.

> but the VTP make process give an error :
>
> [..]
> cd unzip && make all
> mkdir -p /source/VTP/OSX/Frameworks/unzip.framework/Versions/A
> mkdir -p /source/VTP/OSX/Frameworks/unzip.framework/Headers
> ln -s /source/VTP/OSX/Frameworks/unzip.framework/Versions/A /source/
> VTP/OSX/Frameworks/unzip.framework/Versions/Current
> ln: /source/VTP/OSX/Frameworks/unzip.framework/Versions/Current/A:
> File exists
> make[2]: [/source/VTP/OSX/Frameworks/unzip.framework] Error 1
> (ignored)

This seems a little strange. Maybe it's a normal "error" about the library
being already built, really a warning.

> cp ioapi.h iowin32.h unzip.h /source/VTP/OSX/Frameworks/
> unzip.framework/Headers/
> g++ -dynamiclib -o /source/VTP/OSX/Frameworks/vtdata.framework/
> Versions/A/vtdata -install_name @executable_path/../../../Frameworks/
> vtdata.framework/Versions/A/vtdata -compatibility_version 1.2 -
> current_version 1.2.1 -L/usr/local/lib -lgdal -L/sw/lib -lnetcdf -
> lpng -ljpeg -lcurl -lbz2 -lz -F/source/VTP/OSX/Frameworks -framework
> xmlhelper [....]
> ld: Undefined symbols:
> _unzClose
> _unzCloseCurrentFile

I don't see "-framework unzip" on that link line, it should be there.
Perhaps it is in CVS, but not in the last release source.
(Use CVS if you can, many Mac build improvements have been checked in
recently.)

It should be in Make.defs:
VTDATA_LINK_OPTS = $(COMMON_OPTS) \
$(XMLHELPER_OPTS) \
$(UNZIP_OPTS)

-Ben