Ticket #1555 (new enhancement)

Opened 1 year ago

Last modified 10 months ago

Need to allow debug/release builds to coexist

Reported by: brucedechant Assigned to: warmerdam
Priority: normal Milestone:
Component: ConfigBuild Version: 1.4.0
Severity: normal Keywords:
Cc: mloskot

Description

If you mix debug and release CRT libraries on Windows your application will end up crashing. There needs to be a way to allow both debug and release builds to coexist.

Perhaps adding a "d" to the end of the library/dll name to indicate the debug version and building each debug/release in its own sub-folder would help with this.

Attachments

nmake.opt (9.7 kB) - added by brucedechant on 04/03/07 13:14:51.
Updated file
Makefile (4.8 kB) - added by brucedechant on 04/03/07 13:15:14.
Updated file
ogr.vcproj (1.7 kB) - added by brucedechant on 04/03/07 13:15:56.
Updated file
makefile.vc (1.0 kB) - added by brucedechant on 04/03/07 13:16:36.
Updated file
cpl.vcproj (1.7 kB) - added by brucedechant on 04/03/07 13:17:07.
Updated file

Change History

04/03/07 13:14:51 changed by brucedechant

  • attachment nmake.opt added.

Updated file

04/03/07 13:15:14 changed by brucedechant

  • attachment Makefile added.

Updated file

04/03/07 13:15:56 changed by brucedechant

  • attachment ogr.vcproj added.

Updated file

04/03/07 13:16:36 changed by brucedechant

  • attachment makefile.vc added.

Updated file

04/03/07 13:17:07 changed by brucedechant

  • attachment cpl.vcproj added.

Updated file

04/03/07 13:31:24 changed by warmerdam

  • type changed from defect to enhancement.
  • component changed from default to ConfigBuild.

This is an enhancement request.

It is currently possible to do a debug and a release build with the current makefiles, installing them into distinct trees, and setting distinct DLL names by passing distinct values for the VERSION macro. 

eg. 

nmake /f makefile.vc clean
nmake /f makefile.vc 
nmake /f makefile.vc install GDAL_HOME=C:\gdal_release

nmake /f makefile.vc clean
nmake /f makefile.vc OPTFLAGS="/nologo /MD /EHsc /Zi /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Fd$(GDAL_ROOT)\gdal.pdb" VERSION=14d
nmake /f makefile.vc VERSION=14d GDAL_HOME=C:\gdal_debug

I don't see a compelling reason to support distinct release and debug builds in the build tree.

But it might be nice to make doing the above easier.

04/03/07 17:40:11 changed by stevedang

Running a debug or release build will create one library and remove the other. This may lead to the mixed CRT usage problem during development where a release version of the application is linked to a debug version of the library, and vice versa. Note that the VERSION macro only applies to the dynamic library name, not the static one.

Allowing debug and release builds to coexist could be done by one of the following options:

1. The debug and release libraries have a different name and are in the same directory. 2. The debug and release libraries have the same name but are in a different directory. 3. The debug and release libraries have a different name and are in a different directory (Xerces-C project adopts this).

04/03/07 19:29:11 changed by warmerdam

Bruce,

The above mentioned approach installs the debug and release versions of stuff into distinct directories. So the debug and release configurations of the application would point to the appropriate directories.

I am guessing you are in the habit of using the gdal_i.lib directly from the build tree, and I think this is inadivisable.

So I'm basically advocating that you use option "2" - the debug and release stub libraries have the same name, but are in different directories (after being installed).

10/19/07 10:43:09 changed by mloskot

  • cc set to mloskot.