Jason Roberts wrote:
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.
Hmm, I use the compiler as well, but not that
pretend-to-be-a-compiler-one. I use the good old one 6.5 true compiler.
The approach you recommend, renaming those common libraries, seems like a
good way to deal with it.
Actually, I'm afraid it's not that simple. We can't just rename the
dlls, we have to rebuild them with a different name.
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...
Absolutely true according to my experience. TMW, which I know better,
behaves like it has the "King in the belly" (a Portuguese saying). They
just don't give a shit for the official libraries and ship their own
ones, which wouldn't be a problem if it didn't interfere with the
outside world, but they do.
I had also troubles with ArcGis that installed old incompatible
zlib1.dll under Windows/system32. Just imagine the chaos that it
produced on the classroom machines (for that one I'm free, since by
principle I don't get nearer than 5 m to a computer with Arcs in it).
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
