[Gdal-dev] Exception thrown in GDALOpen() function

[Roger James]

Frank,

My changes to the gdal build environment predated your adoption of the
multi threaded dll c runtime library as the default link option. I admit
I have run with my own VC build environment since I made the changes, so
the issues I saw then may well have been resolved.

If at some time you want to revisit the VC build process I will be happy
to assist.

Roger

> -----Original Message-----
> From: gdal-dev-admin at remotesensing.org [mailto:gdal-dev-
> admin at remotesensing.org] On Behalf Of Frank Warmerdam
> Sent: 03 August 2003 16:23
> To: gdal-dev at remotesensing.org
> Subject: Re: [Gdal-dev] Exception thrown in GDALOpen() function
> 
> Roger James wrote:
> 
> > The other issue with mixed libraries occurs when you are using the
dll
> > version of gdal or are linking the static library version into a
dll.
> > You end up with memory being allocated and freed from different
heaps.
> > This is an issue that both Ben and I have come across, and is why we
now
> > run with modified gdal makefiles that build differently named debug
and
> > non debug versions.
> >
> > If you are having to resort to using ignoredefaultlibs then it is
likely
> > that you will eventually run into problems.
> 
> Roger,
> 
> OK, I understand that under some circumstances different DLLs each
have
> their
> own heap.  I have worked under these conditions when using the regular
> LIBC
> instead of the runtime C library with MSVC, and with some care it need
not
> be impossible.  In fact, it was for this reason I introduced some
methods
> like OGRFeature::DestroyFeature() so that an application could pass a
> feature
> to the GDAL DLL to destroy instead of doing it in the parent
application.
> 
> Also, using the GDAL or OGR C APIs you pretty much avoid the heap
issues
> since the C APIs leave all object allocation and destruction within
the
> DLL.
> 
> However, I can see that it may be easier to write safe applications if
you
> use the same runtime library.  However, I haven't yet seen clearly
that it
> is necessary to have the GDAL DLL built with the same build options as
> the parent application.
> 
> 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
> 
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at remotesensing.org
> http://remotesensing.org/mailman/listinfo/gdal-dev