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

[Jason Roberts]

Hi Joaquim,

Thanks for sharing your experience with that. Fortunately I have not hit the
compatibility problem with other libraries. Perhaps it is because I'm using
the MATLAB Compiler / MATLAB Component Runtime (MCR, not mex, and only
referencing a very limited number of MATLAB functions and toolboxes. My
guess is that those other libraries are delay loaded or explicitly loaded,
and that I'm just getting lucky by not using MATLAB to read netCDFs, for
example.

The approach you recommend, renaming those common libraries, seems like a
good way to deal with it.

Frank W mentioned in a private email that he thought that GDAL is using
binaries provided by the Xerces team. If that is indeed the case, then this
Xerces compatibility issue may arise from ESRI or MathWorks compiling their
own Xerces, rather than using the one provided by the Xerces team. In that
case, I would say that ESRI and MathWorks are breaking interoperability, and
I'd have a hard time making a case that GDAL should do anything different...


Jason

-----Original Message-----
From: Joaquim Luis [mailto:jluis at ualg.pt] 
Sent: Monday, November 16, 2009 3:38 PM
To: Jason Roberts
Cc: 'Tamas Szekeres'; 'gdal-dev'
Subject: Re: [gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows
to work around Xerces binary conflicts?

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