[gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for
Windows to work around Xerces binary conflicts?
jason.roberts at duke.edu
Mon Nov 16 15:18:32 EST 2009
Thank you for the specific instructions on that. It sounds very easy. I will
try it out this afternoon.
I know what you mean, that it is difficult to decide on a combination of
dependencies that meets the needs of everyone. I thought that maybe the
presence of a "minimalist" Windows binary on the main download page
indicated that the GDAL team thought that the minimalist combination was
worthwhile to produce on a regular basis. But I can see how choosing things
will be a slippery slope that the team would not want to go down.
As it stands, even with your helpful instructions and SDK, it is not
possible to use GDAL with Xerces support in conjunction with MATLAB, ArcGIS,
or other projects that also leverage Xerces and do the same thing that GDAL
does: compile Xerces with dynamic linking and retain the default name of the
DLL. The ultimate solution to this problem is to have the various projects
that use Xerces adopt a naming or binding convention that prevents the
problem from occurring. Ideally the Xerces team would recognize this problem
and provide guidance. (I have not tried to raise it with them.) Absent that,
perhaps statically linking with Xerces, or changing the DLL name to
something specific to GDAL, would be appropriate.
Of course, this is a classic game theory problem: all the players (GDAL,
ESRI, MathWorks, and others) would prefer that the *other* players take the
effort to compile Xerces in the non-default manner, so that they can
continue to use the default compilation. I am hoping that eventually the
GDAL team would take an interest in this and make a change; getting through
the corporate development processes of ESRI and MathWorks is very hard.
Nonetheless, those organizations are just as much "responsible" for the
problem as GDAL, and I am not offering a negative critique of anyone. I very
much appreciate the efforts of the GDAL team, who save me countless hours in
various ways, even if you don't ever fix this problem. It is just sad when
the dreams of efficient modularity and reuse do not fully deliver, despite
everyone's best efforts, and one finds oneself the loser by reaching for too
much interoperability. (Sorry for the dramatic statement.)
From: Tamas Szekeres [mailto:szekerest at gmail.com]
Sent: Monday, November 16, 2009 2:25 PM
To: Jason Roberts
Subject: Re: [gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows
to work around Xerces binary conflicts?
It's quite difficult to find out what combination of the dependencies
would be demanding for the users, by taking out the significant
components it would be unusable for most of the users.
I just wanted to mention it's quite straightforward exclude xerces
support and recompile gdal, by using the following steps:
1. Download the SDK package for your compiler/architecture from
http://vbkto.dyndns.org/sdk/ and extract it into a directory
2. Check out the current version of gdal from SVN into the SDK root dir.
3. Open Makefile and remove (or comment out) 'GDAL_XERCES = YES' and
set up 'GDAL_DIR = [gdal directory name]'
4. Open a Visual Studio Command Prompt and type: 'nmake gdal'
2009/11/16 Jason Roberts <jason.roberts at duke.edu>:
> Greetings GDAL team,
> The main GDAL download page
> http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries contains a link to
> "minimalist" Windows executables for GDAL 1.6.0, built by Frank W when
> 1.6.0 was released. Is there any possibility you could offer similar
> binaries of 1.6.2 or the upcoming 1.6.3?
> The only other source of up-to-date GDAL Windows binaries I know of is
> http://vbkto.dyndns.org/sdk/, maintained by Tamas S. These are great, but
> unfortunately I cannot use them because they compile a GDAL driver or
> plug-in that links with xerces-c, and my application loads GDAL in ArcGIS
> and MATLAB processes that also link with xerces-c and there is a DLL
> conflict. This issue came up at GDAL 1.6.0 release time and Frank agreed
> rerelease the minimalist 1.6.0 binaries without the Xerces dependency. See
> http://trac.osgeo.org/osgeo4w/ticket/31 for more information about that.
> It would be very helpful to me if you could release these minimalist
> executables with every GDAL bugfix release. I have been limping along on
> 1.6.0, waiting for 1.7.0 (when, presumably, minimalist binaries will be
> released again), but I just hit a SWIG issue that causes parts of OGR in
> 1.6.0 to be incompatible with ArcGIS 9.3. This issue was fixed in SWIG
> 1.3.39. Using Tamas's 1.6.2 binaries built with SWIG 1.3.39, I verified
> the problem is resolved, but I can't use Tamas's binaries in my production
> code due to the Xerces problem.
> So, I am at the point that I will either have to start building minimalist
> binaries 1.6.x myself or delay some new OGR-dependent functionality in my
> app until 1.7.0 minimalist binaries are released (assuming they will be).
> can figure out how to build myself but I'm hoping that by raising this
> Xerces issue again, you might be convinced that minimalist binaries are
> important enough to release them with every bugfix release. What do you
> Thanks very much for your consideration,
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev