On 12-04-2012 16:24, Jeff McKenna wrote:
Hi Joaquim,
I've definitely been in a similar situation before. Most of the time,
when I get those 'LIBCMT' or 'MSVCRT' conflict messages, it is because I
built a dependent library with the /MT option by mistake, causing the
GDAL built to try to include LIBCMT.lib (but GDAL and all of its
dependecies are built with /MD).
Jeff,
Thanks for the input. I have not yet time to check one thing that I
might have change in the last week and could eventually explain the errors.
Someone complained to me that GMT (that uses the GDAL dlls prepared by
me) was not running on a XP64. It turned out that it was and option in
libcurl build. I made one hand change to an header and I think that I
did not rebuild after having reverted the change.
It will be strange that it is the culprit but otherwise I have no idea
on what it is, and I build GDAL on Win for a couple of years now.
As an aside, for everyone reading: I'm kind of surprised to read that
many GDAL-win devs are using MSVC2010 now, I use MSVC2008 because so
many of GDAL's libraries barely 'support' that older version, let alone
the latest. I guess I should look at upgrading to MSVC2010, but I'm
extremely scared about if/how I'll be able to compile some of those
trickier/barely-supported windows dependencies with the new version.
Well, if you build the dependencies your self is a bit of a work, but
most of them have CMake scripts now which greatly simplify the job.
This is probably not yet widely spread out, but one of the GMT
developers (Florian Wobbe) made a CMake build for netCDF4.1.3.
See instructions on
http://gmtrac.soest.hawaii.edu/projects/gmt/wiki/BuildingGMT
Joaquim
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
