[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]

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:warmerdam at pobox.com] 
Sent: Tuesday, December 30, 2008 12:17 PM
To: Jason Roberts
Cc: gdal-dev at lists.osgeo.org
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,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent