the problem I've identified: ---------------------------- a) spatialite depends on freexl b) gdal depends on both freexl and spatialite
the current spatialite 3.0.1-2 DLL distributed by OSGeo4W was linked (inadvertently, I presume) so to include a static internal copy of the freexl library. consequently the current gdal 1.9.2-2 DLL available on OSGeo4W depends on these "static" freexl link symbols expected to be found within spatialite.dll and not within freexl.dll, as it would be more reasonable. the overall result is that any attempt to rebuild spatialite.dll in the "right way" (e.g. avoiding to statically link freexl.lib and depending instead on freexl.dll) will consequently cause fatal errors due to unresolved link symbols when loading gdal.dll e.g. this will make completely impossible starting QGIS; to make things even worst (if possible) Windows poor diagnostic messages will be of very little help in order to identify the real failure cause. I had a big pain in order to really understand what's going wrong in my own QGIS test build. I'm able to foresee only two possible ways to circumvent this dangerous pitfall: A) still continuing to build any new version of spatialite.dll so to statically link freexl (looks really a ugly workaround) B) carefully synchronizing the next release of both spatialite and gdal (may be 1.10 ?) so to safely switch to a "pure dll" approach and thus restoring normality. bye Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ osgeo4w-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/osgeo4w-dev
