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

[Ed McNierney]

Frank -

Actually, I've always found GDAL to be one of the most "buildable" of
MapServer-related libraries on Windows.  Many of the distributions come
with Windows makefiles that are simply broken or hopelessly out-of-date.
For a long time the most annoying problems I had building under Windows
was with the regex-0.12 library, which was all of a few dozen lines of
code in one C file!

I have found that the bigger issues revolve around using the
multithreaded runtime libraries.  Many of the other default makefiles
for Windows (in other libraries) are pretty cryptic so it's not easy to
figure out how to do a multithreaded build.

I have had on my to-do list (for a while) a nicely constructed build
environment for MapServer and supporting libraries under Windows, all
built with the multithreaded libraries.  Now that 4.0's out the door, I
think I'll probably get around to it.

I wouldn't put the release/debug stuff at the top of the GDAL to-do list
- it's possible that I'll take care of it in the next few weeks anyway.

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
Phone: (978) 251-4242  Fax: (978) 251-1396
ed at topozone.com


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Sunday, August 03, 2003 11:34 AM
To: gdal-dev at remotesensing.org
Subject: Re: [Gdal-dev] Exception thrown in GDALOpen() function

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


_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev