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.)
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
