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.) Jason -----Original Message----- From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Monday, November 16, 2009 2:25 PM To: Jason Roberts Cc: gdal-dev Subject: Re: [gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts? Jason, It's quite difficult to find out what combination of the dependencies would be demanding for the users, by taking out the significant components it would be unusable for most of the users. I just wanted to mention it's quite straightforward exclude xerces support and recompile gdal, by using the following steps: 1. Download the SDK package for your compiler/architecture from http://vbkto.dyndns.org/sdk/ and extract it into a directory 2. Check out the current version of gdal from SVN into the SDK root dir. 3. Open Makefile and remove (or comment out) 'GDAL_XERCES = YES' and set up 'GDAL_DIR = [gdal directory name]' 4. Open a Visual Studio Command Prompt and type: 'nmake gdal' Best regards, Tamas 2009/11/16 Jason Roberts <jason.robe...@duke.edu>: > Greetings GDAL team, > > > > The main GDAL download page > http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries contains a link to > "minimalist" Windows executables for GDAL 1.6.0, built by Frank W when GDAL > 1.6.0 was released. Is there any possibility you could offer similar > binaries of 1.6.2 or the upcoming 1.6.3? > > > > The only other source of up-to-date GDAL Windows binaries I know of is > http://vbkto.dyndns.org/sdk/, maintained by Tamas S. These are great, but > unfortunately I cannot use them because they compile a GDAL driver or > plug-in that links with xerces-c, and my application loads GDAL in ArcGIS > and MATLAB processes that also link with xerces-c and there is a DLL > conflict. This issue came up at GDAL 1.6.0 release time and Frank agreed to > rerelease the minimalist 1.6.0 binaries without the Xerces dependency. See > http://trac.osgeo.org/osgeo4w/ticket/31 for more information about that. > > > > It would be very helpful to me if you could release these minimalist Windows > executables with every GDAL bugfix release. I have been limping along on > 1.6.0, waiting for 1.7.0 (when, presumably, minimalist binaries will be > released again), but I just hit a SWIG issue that causes parts of OGR in > 1.6.0 to be incompatible with ArcGIS 9.3. This issue was fixed in SWIG > 1.3.39. Using Tamas's 1.6.2 binaries built with SWIG 1.3.39, I verified that > the problem is resolved, but I can't use Tamas's binaries in my production > code due to the Xerces problem. > > > > So, I am at the point that I will either have to start building minimalist > binaries 1.6.x myself or delay some new OGR-dependent functionality in my > app until 1.7.0 minimalist binaries are released (assuming they will be). I > can figure out how to build myself but I'm hoping that by raising this > Xerces issue again, you might be convinced that minimalist binaries are > important enough to release them with every bugfix release. What do you > think? > > > > Thanks very much for your consideration, > > > > Jason > > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev