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

[Frank Warmerdam]

Ed McNierney wrote:

> Frank -
> 
> It's not a calling convention problem.  The compiler inserts the name of
> the appropriate run-time library in the object module when compiling, so
> the linker will automatically look for it.  If you compile some objects
> debug and some non-debug, the compiler will have inserted both library
> names into those objects; when you go to link, both runtime libraries
> will be linked and you will get symbol redefinition conflicts.
> 
> This can be worked around by telling the linker to ignore all libraries
> specified in the object modules and then explicitly listing all the
> libraries you need, but that's pretty tedious and many users don't
> understand how to do it (or how to do it correctly).

Ed,

Traditionally I built GDAL linking against the static LIBC library
which resulted in GDAL having its own heap.  It was tricky to ensure
objects were allocated and deallocated within the proper heap (as I
noted in the response to Roger), but that aside it didn't seem to matter
what options the mainline application used since the DLL was completely
self contained, with it's own copy of all the C library code it used.

I can certainly see that if an application was linking against the static
libraries for GDAL/OGR (those containing all the real object code as opposed
to just the DLL stub libraries which I assume have no dependencies on
external runtime libraries or static libraries) that things would be
confused with different object files requesting C library functions from
different LIBC's (either the non-debug or the debug one for instance).

I too have on occasion used the "ignore all libraries" directive.  As far as
I know it worked most of the time with some caveats.

But, is it true that you can't link DLLs into an application that depend on
different C runtime libraries?  If so, would it be better if I went back to
having GDAL built linked against the static LIBC instead of the C runtime
library?  It seems this would make GDAL's DLL self contained at the cost
of folks having to be very careful about heap issues in application code.

Argg.  It seems to be a tradeoff situation.  Of course, it might be better
if I just made it easy to build "release" and "debug" versions of everything
conveniently on win32, like folks do in Visual Studio.

Once Alessandro finishes reworking and streamlining the build process on
Unix, I am willing to revisit the windows build again to see what I can do
in this regard.

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