[gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts?

[Joaquim Luis]

Jason,

In what concerns TheMathWorks (Matlab), it's not only xercers that you 
must worry about but also netCDF, zlib1 and very likely some others. For 
example many ML releases used an old, or not compatible, zlib1.dll that 
simply got in the way and screwed everything. Now they are more modern 
and use manifest, which potentially screw you in the same way.
I solved that by creating (recompiling) zlib1, netcdf, libjpeg, ... with 
different names so that they be called and used peacefully from my GDAL 
based mexs (which don't link against Xerces).

Joaquim Luis

> Tamas,
>
> 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.)
>