[gdal-dev] gdal-dev Digest, Vol 118, Issue 58

Thu Mar 27 04:46:07 PDT 2014

On Thu, Mar 27, 2014 at 3:21 AM, ridgewang <ridgewang at gmail.com> wrote:

> Hi，
>     I have 2 suggestions：
> 1. supply an option that can build the gdal using the static c++ runtime
> library, so we can use it not depends on the msvcr80.dll and msvcp80.dll.
>
> 2. provide a gdal_merge.exe utility program with the same function as
> gdal_merge.py.
>

you can use the gdalwarp utility instead - it works better for me anyway.

>
> here are the reasons I raise it:
> 1. I write a COM component using gdal  library, but I can not register the
> component correction, maybe the version in my computer is not right and I
> donot known how to build a static version not using the vc runtime library.
>
> 2. I do not known how to run the python utility and it always reports
> cannot find the _gdal module, and I had tried many times and had set the
> pythonpath environment variance.
>
> And who can kindly teach me how to solve the first problem. Maybe I can
> add some switch option to the compile configuration file?
>
> Ridge
>
>
>
>
>
>
> 在 2014-3-27，3:00，gdal-dev-request at lists.osgeo.org 写道：
>
> > Send gdal-dev mailing list submissions to
> >    gdal-dev at lists.osgeo.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >    http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > or, via email, send a message with subject or body 'help' to
> >    gdal-dev-request at lists.osgeo.org
> >
> > You can reach the person managing the list at
> >    gdal-dev-owner at lists.osgeo.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of gdal-dev digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re: GDAL 1.11 release plan (Even Rouault)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 26 Mar 2014 16:16:24 +0100
> > From: Even Rouault <even.rouault at mines-paris.org>
> > To: Olivier BARTHELEMY <barthelemy at geovariances.com>
> > Cc: gdal-dev at lists.osgeo.org
> > Subject: Re: [gdal-dev] GDAL 1.11 release plan
> > Message-ID: <1395846984.5332ef48e324c at imp.free.fr>
> > Content-Type: text/plain; charset=ISO-8859-15
> >
> > Selon Olivier BARTHELEMY <barthelemy at geovariances.com>:
> >
> > I've fixed the one in adrgdataset.cpp.
> > gifalloc.c, degrib18, hdf-eos are third-party code "imported" into GDAL
> tree. So
> > the best way would be to fix the issues upstream (if fix is actually
> needed) and
> > then downstream into GDAL.
> > I've analyze errors reported in rasterlitedataset.cpp, ogrdatasource.cpp,
> > ogrpgdatasource.cpp and strtod, and they are false positives.  So the
> rate of
> > false positives with cppcheck is quite significant.
> > I haven't looked at the other files that I'm less familiar with.
> >
> > Even
> >
> >> Here is what cppcheck 1.64 reports as 'errors' in gdal-1.10.1:
> >>
> >> [frmts\adrg\adrgdataset.cpp:1071]: (error) Memory leak: TILEINDEX
> >> [frmts\coasp\coasp_dataset.cpp:199]: (error) Undefined behavior:
> Variable
> >> 'pszItemValue' is used as parameter and destination in s[n]printf().
> >> [frmts\dted\dted_create.c:181]: (error) Resource leak: fp
> >> [frmts\envisat\EnvisatFile.c:286]: (error) Memory leak: self
> >> [frmts\envisat\EnvisatFile.c:609]: (error) Memory leak: dsd_text
> >> [frmts\envisat\EnvisatFile.c:1776]: (error) Memory leak: entry
> >> [frmts\georaster\georaster_dataset.cpp:188]: (error) Possible null
> pointer
> >> dereference: poGRD
> >> [frmts\georaster\georaster_dataset.cpp:189]: (error) Possible null
> pointer
> >> dereference: poGRD
> >> [frmts\georaster\georaster_dataset.cpp:190]: (error) Possible null
> pointer
> >> dereference: poGRD
> >> [frmts\georaster\georaster_dataset.cpp:191]: (error) Possible null
> pointer
> >> dereference: poGRD
> >> [frmts\georaster\oci_wrapper.cpp:1590]: (error) Pointer to local array
> >> variable returned.
> >> [frmts\gif\giflib\gifalloc.c:67]: (error) Memory leak: Object
> >> [frmts\grib\degrib18\degrib\clock.c:2071]: (error) Common realloc
> mistake:
> >> 'Stack' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\clock.c:2175]: (error) Common realloc
> mistake:
> >> 'Rel' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\clock.c:2197]: (error) Common realloc
> mistake:
> >> 'Rel' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\clock.c:2209]: (error) Common realloc
> mistake:
> >> 'Rel' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\grib2api.c:594]: (error) Uninitialized
> >> variable: igdstmpl
> >> [frmts\grib\degrib18\degrib\metaparse.cpp:2628]: (error) Common realloc
> >> mistake: 'freq' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:109]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:126]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:132]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:149]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:158]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:187]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:195]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:203]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:211]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:218]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:229]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:241]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:257]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:442]: (error) Common realloc
> mistake:
> >> 'preBuffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myerror.c:534]: (error) Common realloc
> mistake:
> >> 'buff' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myutil.c:85]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myutil.c:92]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myutil.c:99]: (error) Common realloc
> mistake:
> >> 'buffer' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\myutil.c:149]: (error) Common realloc
> mistake:
> >> 'argv' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\tdlpack.cpp:3256]: (error) Common realloc
> >> mistake: 'subGroup' nulled but not freed upon failure
> >> [frmts\grib\degrib18\degrib\tdlpack.cpp:4179]: (error) Read and write
> >> operations without a call to a positioning function (fseek, fsetpos or
> >> rewind) or fflush in between result in undefined behaviour.
> >> [frmts\grib\degrib18\g2clib-1.0.4\compack.c:159]: (error) Uninitialized
> >> variable: ival1
> >> [frmts\grib\degrib18\g2clib-1.0.4\comunpack.c:198]: (error) Memory leak:
> >> ifld
> >> [frmts\grib\degrib18\g2clib-1.0.4\misspack.c:203]: (error) Uninitialized
> >> variable: ival1
> >> [frmts\grib\degrib18\g2clib-1.0.4\misspack.c:118]: (error) Uninitialized
> >> variable: rmisss
> >> [frmts\grib\degrib18\g2clib-1.0.4\pngunpack.c:61]: (error) Memory leak:
> ifld
> >> [frmts\grib\degrib18\g2clib-1.0.4\pngunpack.c:61]: (error) Memory leak:
> >> ctemp
> >> [frmts\hdf4\hdf-eos\EHapi.c:2315]: (error) Common realloc mistake:
> >> 'metabuf' nulled but not freed upon failure
> >> [frmts\hdf4\hdf-eos\EHapi.c:3665]: (error) Common realloc mistake:
> >> 'EHXtypeTable' nulled but not freed upon failure
> >> [frmts\hdf4\hdf-eos\EHapi.c:3668]: (error) Common realloc mistake:
> >> 'EHXacsTable' nulled but not freed upon failure
> >> [frmts\hdf4\hdf-eos\EHapi.c:3671]: (error) Common realloc mistake:
> >> 'EHXfidTable' nulled but not freed upon failure
> >> [frmts\hdf4\hdf-eos\EHapi.c:3674]: (error) Common realloc mistake:
> >> 'EHXsdTable' nulled but not freed upon failure
> >> [frmts\hdf4\hdf-eos\GDapi.c:2411]: (error) Array 'HDFcomp[5]' accessed
> at
> >> index 19, which is out of bounds.
> >> [frmts\hdf4\hdf-eos\GDapi.c:2177]: (error) Array 'originNames[4]'
> accessed
> >> at index 15, which is out of bounds.
> >> [frmts\hdf4\hdf-eos\GDapi.c:2292]: (error) Array 'pixregNames[2]'
> accessed
> >> at index 7, which is out of bounds.
> >> [frmts\hdf4\hdf-eos\SWapi.c:4995]: (error) Memory leak: fillbuf
> >> [frmts\hdf4\hdf-eos\SWapi.c:5615]: (error) Memory leak: flag
> >> [frmts\hdf4\hdf-eos\SWapi.c:6239]: (error) Memory leak: flag
> >> [frmts\idrisi\IdrisiDataset.cpp:1886]: (error) syntax error
> >> [frmts\ilwis\ilwisdataset.cpp:1425]: (error) syntax error
> >> [frmts\msg\msgdataset.cpp:532]: (error) Object pointed by an 'auto_ptr'
> is
> >> destroyed using operator 'delete'. You should not use 'auto_ptr' for
> >> pointers obtained with operator 'new[]'.
> >> [frmts\netcdf\netcdfdataset.cpp:5997]: (error) Uninitialized variable:
> >> strtime
> >> [frmts\pcidsk\sdk\core\pcidsk_utils.cpp:644]: (error) Common realloc
> >> mistake: 'pszWorkBuffer' nulled but not freed upon failure
> >> [frmts\pcidsk\sdk\core\pcidskexception.cpp:170]: (error) Common realloc
> >> mistake: 'pszWorkBuffer' nulled but not freed upon failure
> >> [frmts\png\libpng\pngrutil.c:996]: (error) Uninitialized variable:
> igamma
> >> [frmts\rasterlite\rasterlitedataset.cpp:1179]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1185]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1186]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1187]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1188]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1190]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1191]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1192]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1193]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1194]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1195]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1196]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\rasterlite\rasterlitedataset.cpp:1267]: (error) Possible null
> >> pointer dereference: poDS
> >> [frmts\raw\atlsci_spheroid.cpp:122]: (error) syntax error
> >> [frmts\raw\mffdataset.cpp:1451]: (error) syntax error
> >> [frmts\sgi\sgidataset.cpp:523]: (error) Using 'memcpy' on struct that
> >> contains a 'std::string'.
> >> [ogr\ogrsf_frmts\dgn\dgnhelp.cpp:1379]: (error) syntax error
> >> [ogr\ogrsf_frmts\dwg\ogrdwglayer.cpp:323]: (error) Invalid number of
> >> character ({) when these macros are defined: 'notdef'.
> >> [ogr\ogrsf_frmts\filegdb\FGdbLayer.cpp:1914]: (error) syntax error
> >> [ogr\ogrsf_frmts\generic\ogrdatasource.cpp:1425]: (error) Possible null
> >> pointer dereference: papoSrcLayers
> >> [ogr\ogrsf_frmts\mitab\mitab_coordsys.cpp:747]: (error) Buffer is
> accessed
> >> out of bounds.
> >> [ogr\ogrsf_frmts\mitab\mitab_geometry.cpp:223]: (error) Memory leak:
> >> xintersect
> >> [ogr\ogrsf_frmts\ntf\ntffilereader.cpp:260]: (error) Memory pointed to
> by
> >> 'poRecord' is freed twice.
> >> [ogr\ogrsf_frmts\pg\ogrpgdatasource.cpp:1102]: (error) Memory leak:
> poLayer
> >> [ogr\ogrsf_frmts\shape\shptree.c:241]: (error) Memory leak: psTree
> >> [port\cpl_minizip_zip.cpp:608]: (error) Memory leak: zi
> >> [port\cpl_strtod.cpp:67]: (error) Division by zero.
> >>
> >> I'd be happy to provide fix patches, but i have not much time at the
> >> moment, so it won't be before a 1.11 release.
> >>
> >> If you want to see the other 'warnings', and get un updated report on
> GDAL
> >> trunk, maybe you could ask to those who manage
> >> http://debbie.postgis.net:8080/view/GDAL/ to add the cppcheck plugin to
> >> their Jenkins?
> >>
> >>
> >> 2014-03-26 9:15 GMT+01:00 Even Rouault <even.rouault at mines-paris.org>:
> >>
> >>> Hi Olivier,
> >>>
> >>> If you could share with us the errors that have been reported (and the
> >>> options
> >>> you have used to pass cppcheck on GDAL source), that would be a good
> >>> contribution. Even better if you can submit a patch to fix them ;-)
> >>> Not saying they shouldn't be fixed, but I don't see that as a blocker
> point
> >>> however, unless they show up in nominal code paths. They have likely
> >>> existed for
> >>> years.
> >>> We also have registered GDAL to the Coverity scanner, and we try to fix
> >>> errors
> >>> that are reported in new code.
> >>>
> >>> Even
> >>>
> >>>> I think you should take a look at what cppcheck finds when scanning
> GDAL
> >>>> source before the next release. There are a few tens of small errors.
> >>>> Mostly, small leaks in particalr cases. Not very important errors, but
> >>> that
> >>>> ought to be fixed before doing an release in my opinion
> >>>>
> >>>>
> >>>> 2014-03-26 8:49 GMT+01:00 Paul Meems <bontepaarden at gmail.com>:
> >>>>
> >>>>> +1 for adding VS2013 binaries in GISInternals
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>> *Paul Meems *
> >>>>> Release manager, configuration manager
> >>>>> and forum moderator of MapWindow GIS.
> >>>>> www.mapwindow.org
> >>>>>
> >>>>> Owner of MapWindow.nl - Support for
> >>>>> Dutch speaking users.
> >>>>> www.mapwindow.nl
> >>>>>
> >>>>>
> >>>>>
> >>>>> *Join us at the MapWindow GIS Conference 2014
> >>>>> <http://geogis.detek.unideb.hu/TKonferencia/2014/>, in Debrecen
> >>> Hungary*
> >>>>>
> >>>>>
> >>>>> 2014-03-26 6:25 GMT+01:00 xavier lhomme <lhomme.xavier at gmail.com>:
> >>>>>
> >>>>> Hi
> >>>>>>  Adding Visual Studio 2012 2013 in GISInternals for Gdal 1.11 should
> >>> be
> >>>>>> great too.
> >>>>>> Xav
> >>>>>> Le 25 mars 2014 22:57, "Tamas Szekeres" <szekerest at gmail.com> a
> >>> ?crit :
> >>>>>>
> >>>>>> That sounds good to me.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Tamas
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2014-03-25 22:37 GMT+01:00 Even Rouault <
> >>> even.rouault at mines-paris.org>:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> GDAL 1.10 was released about one year ago, so it is time to think
> >>> about
> >>>>>>>> the next
> >>>>>>>> release. I think we should just call it 1.11 given that there are
> no
> >>>>>>>> major
> >>>>>>>> architectural changes (although there have been non trivial
> changes
> >>> in
> >>>>>>>> RAT
> >>>>>>>> management and for multiple geometry field support, but that only
> >>>>>>>> impacts core &
> >>>>>>>> drivers), and the C API and ABI is still preserved (for those who
> >>> have
> >>>>>>>> looked at
> >>>>>>>> the other thread, my experiments on unification are *not* in
> trunk).
> >>>>>>>> For the
> >>>>>>>> details, I have initiated the preliminary NEWS :
> >>>>>>>> http://trac.osgeo.org/gdal/export/27091/trunk/gdal/NEWS (*)
> >>>>>>>> There are some mentions to 2.0 in the documentation of new
> features,
> >>>>>>>> but I'll
> >>>>>>>> end up fixing them to reflect the 1.11 numbering.
> >>>>>>>>
> >>>>>>>> I think we are in a good shape to start the beta phase soon. If
> >>> people
> >>>>>>>> have
> >>>>>>>> features or bug fixes almost ready that they'd like to be in 1.11,
> >>>>>>>> please speak
> >>>>>>>> up now. Otherwise I suggest issuing a beta-1 at the end of next
> >>> week,
> >>>>>>>> give it a
> >>>>>>>> week for testing, and depending on the outcome, issue a beta-2, or
> >>> just
> >>>>>>>> try
> >>>>>>>> RC-1. Unless someone volunteers (the process is fairly well
> >>> documented
> >>>>>>>> in
> >>>>>>>> HOWTO-RELEASE), I can be release manager for 1.11.
> >>>>>>>>
> >>>>>>>> Any opinion about that plan ?
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>
> >>>>>>>> Even
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Geospatial professional services
> >>>>>>>> http://even.rouault.free.fr/services.html
> >>>>>>>> _______________________________________________
> >>>>>>>> gdal-dev mailing list
> >>>>>>>> gdal-dev at lists.osgeo.org
> >>>>>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> gdal-dev mailing list
> >>>>>>> gdal-dev at lists.osgeo.org
> >>>>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> gdal-dev mailing list
> >>>>>> gdal-dev at lists.osgeo.org
> >>>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> gdal-dev mailing list
> >>>>> gdal-dev at lists.osgeo.org
> >>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> [image: Geovariances]
> >>>>
> >>>> Olivier BARTHELEMY *Software development engineer*
> >>>> Geovariances, 49bis avenue Franklin Roosevelt - 77215 AVON CEDEX -
> FRANCE
> >>>> | www.geovariances.com <http://link.geovariances.com/eml-home>
> >>>> Keep posted about Geovariances   <
> >>> http://link.geovariances.com/eml-geowidget>
> >>>>    <http://link.geovariances.com/eml-linkedin-gv>
> >>>> <http://link.geovariances.com/eml-linkedin>
> >>>>    <http://link.geovariances.com/eml-twitter>
> >>>> <http://link.geovariances.com/eml-youtube>
> >>>>    <http://link.geovariances.com/eml-slideshare>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> [image: Geovariances]
> >>
> >> Olivier BARTHELEMY *Software development engineer*
> >> Geovariances, 49bis avenue Franklin Roosevelt - 77215 AVON CEDEX -
> FRANCE
> >> | www.geovariances.com <http://link.geovariances.com/eml-home>
> >> Keep posted about Geovariances   <
> http://link.geovariances.com/eml-geowidget>
> >>    <http://link.geovariances.com/eml-linkedin-gv>
> >> <http://link.geovariances.com/eml-linkedin>
> >>    <http://link.geovariances.com/eml-twitter>
> >> <http://link.geovariances.com/eml-youtube>
> >>    <http://link.geovariances.com/eml-slideshare>
> >>
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > End of gdal-dev Digest, Vol 118, Issue 58
> > *****************************************
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140327/473cd92d/attachment-0001.html>