Building Fortran Windows PGPlot

[rorban]

I am trying to build PGPlot for Windows using the v 14.0.0092.11 Fortran compiler and Developer Studio 2012 and encountered a problem that I don't understand.

I followed the directions here:

http://sukhbinder.wordpress.com/2011/09/17/installing-and-using-pgplot-in-windows/

and was able to successfully build a static library, pgplot.lib, using the Static Library project type in Developer Studio. I built one library for debug mode and one library for release mode.

I then attempted to build and run the first example, pgdemo1.f, as a QuickWin application, as described in the webpage refered above.. This was successful in release mode, where I linked against the version of pgplot.lib that I had originally built in release mode.

However, I could not built in debug mode. (I tried linking against the version of pgplot.lib that I had built in debug mode). When I tried to build the example, I got the following two error messages from the linker:

Error    1     error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)    MSVCRTD.lib(ti_inst.obj)

Error    2     error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)    MSVCRTD.lib(ti_inst.obj) 

Error    4     fatal error LNK1169: one or more multiply defined symbols found    Debug\pgplotExample.exe       

Other than specifying the path to pgplot.lib in Linker/Input/Additional Dependencies and  setting Properties/Fortran/Data/Use Bytes as RECL=Unit for Unformatted Files, I used the defaults that Developer Studio created when I created the "QuickWin" project, which I presume includes the libraries.

What do I do to resolve this conflict between libraries in debug mode? Thanks for any insight.

[mecej4]

See the article Specifying Consistent Library Types . As you can see in the article, specifying /libs:qwin causes the multithreaded static libraries to be requested at link time. Multiple definitions can occur if the Pgplot library was built with a different runtime library option than the example programs.

Secondly, I do not see why you want to build and use a debug version of the Pgplot library, unless you wish to debug the library code itself. 

[rorban]

The reason that I wanted to build a debug version of the PGPlot library is so that I could link it to debug builds of projects I was working on that used the library -- in other words, so I could debug these projects using all the features of the debugger. Or is it possible to link the release-mode PGPlot library into a larger project that was built in debug mode? (As you so probably surmise, I don't know very much about what goes on 'under the hood' in debug builds vs. release builds.)

I was also originally curious as to why in the release build, there was no conflict between the libraries when I simply took the defaults based on Project Type; the problem only happened only in the debug build, although the article you reference explains this. 

[dboggs]

Re: use of debug application development with Release libraries:

I struggled with this a year or two ago. The desirability of mixing made sense to me, but inconsistencies and mysterious (to me) errors occurred. Help obtained from this forum implied, quite clearly, that mixing the two was a bad idea and I had to resort to maintaining both debug and release versions of our own static library. Did I misinterpret the advice? Should I dig up and review that past correspondence? 

[mecej4]

When I use a well-established and widely used software library such as Pgplot or IMSL, I expect any errors to originate from my code, not from the library. Often, the library is distributed only in precompiled form (.LIB or .DLL form). In both situations, what I expect is that the debugger will step over calls to routines in the library.

Almost never do I want to step through the source code of the library routines, even if they are available -- in other words, I want the library routines to be "black-box" in behavior. Let the library developers fix bugs in their code, if any; we have enough problems of our own to deal with.

For these reasons, I have almost no use for debug libraries and debug symbol files. Consider the IMSL library, for example. The standard distributions provide static and dynamic versions of the libraries, and these are all "release" versions. No "debug" libraries are provided.

There is a section in the IFort documentation called "Specifying Consistent Library Types", wherein it says: "Intel Fortran does not select debug libraries for any configuration, but provides settings that allow you to request their use".