Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

release and debug executables on windows

alienpenguin
Beginner
629 Views
Hi all, i would love to have some insights on the behaviour of the icc on windows platforms. On Windows i have used Visual Studio so far, but now i found an issue with that: if i create a library with it and create a "release" build (so that i can sell it to customers) it will then be linked with the msvcrt.dll that is the multithreaded run-time. Creating an application (that use the aforementioned library) in "debug" will link it againt the msvcrtd.dll hence the result will be suing two different runtimes.
In such a case if a library method tried to return something with an allocated pointer i.e. a std::string that would result in heap corruption.
What is the behaviour of ICC? can i create a dll that return arbitrarily complex types and link it against an app that runs in debug mode (i can set breakpoint and such?) ?

thanks
0 Kudos
6 Replies
mecej4
Honored Contributor III
629 Views
There is no requirement that objects created by you with debug symbols present must be linked with debug versions of the compiler runtime and OS routines. Unless you suspect errors in the system libraries, you normally are better off using the release versions of those libraries, and not have to trace through them while debugging your code.

The compiler and linker have switches and options to help you control which libraries are linked in. It is up to you to make sure that you do not build with an incompatible mix of release and debug versions of libraries.
0 Kudos
alienpenguin
Beginner
629 Views
Hi mecej4 and thanks for the reply, i have yet no experience with intel compiler so , maybe my question is a bit dumb.
You said that "it's up to me to make sure not to build with incompatible mix of release and debug versions of libraries" but i have control just over what i compile for myself.
I.e. i create with intel compiler a library, compile in release mode and then make the binary available to whoever wants to use it. Now say Developer1 decides to give the library a try and wants to develop an application using this library of mine; he will first develop a "debug" build of his App but he would be forced to link it to the "release" build of the library.
Would this scenario issue any problems? Again, maybe with intel compiler this is just a non-issue but with Visual C++ every project (app or dll) links against a specific C/C++ run-time depending if you are building in "debug" or in "release" mode and you cannot mix those: an app that is being built in "debug" will easily encounter problem if using a library built in "release".

thanks again
0 Kudos
mecej4
Honored Contributor III
629 Views
The question has little to do with whether the Intel C or MS C compiler is used. It has to do with whether or not you intend to let Developer1 debug your library code instead-of / in-addition-to his/her application code. Unless you intend to provide Developer1 the source code of your library, delivering a "debug version" of your library will provide few benefits over a delivered "release version".

The /Zi option is the one that inserts debug symbols in your library. The /MD or /MDd options let you specify which versions of the runtime to list in the form of /INCLUDELIB directives in the objects that you create.

When I develop a character-mode application in C or Fortran, I usually assume that the language and OS libraries are bug free. When I compile my sources with the /Zi /MD options I get source-level debugging information for my code only, and that is how I want things to be. I can still step through MSVCR90.DLL at the assembly code level (if my debugger provides disassembly), but only if I choose to do so. If I had used /Zi /MDd, I would be using MSVCR90D.DLL instead, the code in the DLL could have more parameter and boundary condition checking, as outlined here. However, unless I had the source code and symbol information for the DLL available, I'd be limited to debugging at the assembly level.

If you use the IDE instead of the command line, these remarks apply unchanged, with the exception of how to set compiler options. You can even speciy command line style options in one of the menus. After all, in many respects an IDE resembles a voluntarily worn straitjacket.
0 Kudos
alienpenguin
Beginner
629 Views
Quoting mecej4
The question has little to do with whether the Intel C or MS C compiler is used. It has to do with whether or not you intend to let Developer1 debug your library code instead-of / in-addition-to his/her application code. Unless you intend to provide Developer1 the source code of your library, delivering a "debug version" of your library will provide few benefits over a delivered "release version".

The /Zi option is the one that inserts debug symbols in your library. The /MD or /MDd options let you specify which versions of the runtime to list in the form of /INCLUDELIB directives in the objects that you create.

That's the whole point, I do not want Developer1 to debug my code (that is compiled with /MD and no /Zi) but I want him to debug his code :) and he will usually compile with /MDd, so if a method of the library returned something like std::string it would mess all up due to heap corruption, so i have to forewarn him that he should compile his debug code with /MD and not with /MDd (that is a constraint i would like not to impose)

So maybe my question could be summed as: intel compiled binary relies on MSVCR90.dll?

Does that make any sense?

0 Kudos
mecej4
Honored Contributor III
629 Views
Your response clarifies why you may have to coordinate with your library user so that his/her .EXE does not end up calling MSVCR90.dll and MSVCR90D.dll, although I don't see why he/she would elect to specify /MDd.

You can find out which DLLs are used by an EXE or DLL using the DUMPBIN facility of the linker:

dumpbin /imports | find /i "dll"

or use the DEPENDS.EXE tool that was provided with earlier SDKs, or the newer Dependency Walker from www.dependencywalker.com .

If you deliver a static library, your user can use the linker option /nodefaultlibrary:<...> to override whatever CRT is specified in that static library, thereby avoiding the use of more than one CRT library.
0 Kudos
alienpenguin
Beginner
629 Views
Quoting mecej4
Your response clarifies why you may have to coordinate with your library user so that his/her .EXE does not end up calling MSVCR90.dll and MSVCR90D.dll, although I don't see why he/she would elect to specify /MDd.

You can find out which DLLs are used by an EXE or DLL using the DUMPBIN facility of the linker:

dumpbin /imports | find /i "dll"

or use the DEPENDS.EXE tool that was provided with earlier SDKs, or the newer Dependency Walker from www.dependencywalker.com .

If you deliver a static library, your user can use the linker option /nodefaultlibrary:<...> to override whatever CRT is specified in that static library, thereby avoiding the use of more than one CRT library.

Well, as you mentioned before, using /MDd might give access to boundary checking codes and such that Developer1 might want to use to debug his own code. As i said, i would love not to impose any unavoidable costraint.

For example I did check the IPP libraries with dependency walker and they seem not to depend at all on any msvcrt[80|90|100].dll but just on msvcrt.dll (system wide windows c runtime?) how such a task is achieved? compiling with icc would do that? would not this solve the issue?

thanks for your support :)

0 Kudos
Reply