Hi Frank, Thanks for the quick reply.
> This is not a new dependency. GDAL has optionally used xerces for some time. > Perhaps the issue is just that the standard binaries now link against this > library? Ok, that is probably what I meant. The standard GDAL 1.6.0 win32 binary release (http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip) includes the xerces DLL and gdal16.dll links to it, whereas the standard 1.5.0 release (http://download.osgeo.org/gdal/win32/1.5/gdalwin32exe150.zip) does not include xerces and gdal15.dll does not link to it. Because of this, I did not encounter the compatibility problem with 1.5, and now encounter it with 1.6, using the standard binaries. > I was under the impression I used the "stock" xerces 2.7 binaries distributed > by the xerces project so I'm somewhat suprised at the degree of compatability > problems. But I could be wrong about having done that. I attempted to find the stock xerces 2.7 binaries. Because xerces has moved on to 2.8, the 2.7 binaries are not available at the main xerces download site http://xerces.apache.org/xerces-c/download.cgi. The most official fall-back site appears to be http://archive.apache.org/dist/xml/xerces-c/Xerces-C_2_7_0/binaries/. That contains only one windows release, xerces-c_2_7_0-windows_2000-msvc_60.zip. The xerces-c_2_7.dll within it has a different size (2,367,488 bytes) than the GDAL 1.6 one (1,757,184 bytes). Can you point me to the one you downloaded and included in GDAL? Regardless of whether you are using the stock binary or not, it is evident that either MATLAB or ArcGIS or both are not using it: MATLAB's size: 1,839,104, ArcGIS's size: 1,687,552. My guess is that they compiled their own copies (probably using a newer version of VC) or there is some Apache archive that I have not located that includes stock binaries built with newer compilers. > If the xerces dependency is too much of a problem, I could regenerate stock > GDAL binaries without the xerces dependency. I could also potentially build > a renamed xerces to avoid conflicts, though I kind of hate doing that when > the project provides stock binaries. If everyone used the same single stock binary, this problem would not occur. But if people compile their own copies, or there are multiple incompatible stock binaries with the same name, there will likely be problems. Given that you are trying to do the right thing and use the stock binary, I hesitate to urge you to regenerate your binaries without the xerces dependency or with a renamed DLL. But the fact is, if you do not, the GDAL DLL you have released cannot be used in a process that also loads MATLAB or ArcGIS DLLs (at least until we can get MathWorks and ESRI to recognize the problem and start using stock DLLs). That writes off a potentially large group of users, including me. So if it is not too much trouble to begin releasing parallel GDAL builds that do not link to xerces, it could benefit many people. If you think the cost/benefit is not there, I can probably start compiling my own copy of GDAL. Thanks, Jason -----Original Message----- From: Frank Warmerdam [mailto:[email protected]] Sent: Tuesday, December 30, 2008 12:17 PM To: Jason Roberts Cc: [email protected] Subject: Re: [gdal-dev] How can you use GDAL from a process that has already loaded some other app's xerces-c_2_7.dll? Jason Roberts wrote: > With the 1.6 release, GDAL for win32 appears to have taken a new dependency > on xerces-c_2_7.dll. Unfortunately this causes compatibility problems with > other applications. Jason, This is not a new dependency. GDAL has optionally used xerces for some time. Perhaps the issue is just that the standard binaries now link against this library? > Any idea how to get this done? I would suggest just recompiling a GDAL binary without use of Xerces-c assuming you have no pressing need for GML support. > Ideally, every app that compiles its own xerces-c_2_7.dll should either give > it a private name or leverage the Windows side-by-side (sxs) infrastructure. > Because everybody is using it, you could say xerces-c_2_7.dll now has > equivalent status to libraries such as MSVCRT. Any chance that GDAL could > employ one of these solutions so that it may be called from programs that > also load ArcGIS 9.3 or MATLAB DLLs? I was under the impression I used the "stock" xerces 2.7 binaries distributed by the xerces project so I'm somewhat suprised at the degree of compatability problems. But I could be wrong about having done that. I'm afraid I don't understand the "side-by-side" stuff, and I'm concerned about adding any dependencies on stuff that won't work on older systems. I'd also note that GDAL's standard binaries are still built with VC7.1 (aka Visual Studio 2003) which doesn't seem to produce manifests which I assume are part of the sxs stuff. If the xerces dependency is too much of a problem, I could regenerate stock GDAL binaries without the xerces dependency. I could also potentially build a renamed xerces to avoid conflicts, though I kind of hate doing that when the project provides stock binaries. Best regards, -- ---------------------------------------+------------------------------------ -- I set the clouds in motion - turn up | Frank Warmerdam, [email protected] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
