Bugs & runtime error linking with LIBCMTD.DLL in Managed C++

[Guest]

Hello everyone

I'm encountering a R6002 Runtime error and several bugs when trying to generate a simple Managed C++ application with .NET 2003. The main problem seems to arise from linking with LIBCMT(D).DLL. (My requirement is that we can't link with MSVCRT(D).LIB.) Below are steps I've followed, and the resulting problems

1. Using the New Project wizard, generate a Visual C++ .NET Class Library project (call it "Doomed") and a VC++ .NET Console Application as a tester (call it "DoomedTester") for the Class Library project. Compile both

BUG #1: When compiling the Doomed class library project, the linker yields the following warning

nochkclr.obj : warning LNK4099: PDB 'libc.pdb' was not found with 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib\nochkclr.obj' or at 'C:\Projects\Doomed\Debug\libc.pdb'; linking object as if no debug inf

2. Add the following code to Doomed.h inside Doomed::Class1

file: Doomed.
-------------
// Doomed.

#pragma onc

using namespace System

namespace Doome

public __gc class Class

public: // Add thi
static void f(); // Add thi
}


3. Add the following code to Doomed.cpp and recompile

file: Doomed.cp
---------------
// This is the main DLL file

#include "stdafx.h
#include <cstdio> // Add thi
#include "Doomed.h

// Add the following code
namespace Doome

void Class1::f(

printf("%f", 1.0)



4. The linker can't resolve printf(), so add LIBCMTD.LIB to Linker->Input->Additional Dependencies, and relink

BUG #2: The linker returns with the following error

LIBCMTD.LIB(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function _mainCRTStartu

(Note: This could be resolved by linking with MSVCRTD.LIB instead, but this isn't what I want to do.

5. Add the dummy code "int main() {}" to Doomed.cpp and rebuild, which resolves the above linker error

BUG #3: The compiler didn't notice that my dummy main() isn't returning a value

6. Add the following code to DoomedTester.cpp and rebuild

file: DoomedTester.cp
---------------------
// This is the main project file for VC++ application project
// generated using an Application Wizard

#include "stdafx.h

#using <mscorlib.dll
#using <Doomed.dll> // Add thi
using namespace System

int _tmain(

Doomed::Class1::f(); // Add thi
return 0


7. Run DoomedTester.exe

BUG #4: I get the following exception

An unhandled exception of type 'System.StackOverflowException' occurred in doomed.dl

(Note: Again, this could be resolved by linking with MSVCRTD.LIB instead, but this isn't what I want to do.

8. From MS KB article 814472 (http://support.microsoft.com/?id=814472), follow the "Modify DLL That Contains Consumers That Use Managed Code and DLL Exports or Managed Entry Points" discussion and add ManagedWrapper.cpp to the Doomed project, and add the appropriate calling code to DoomedTester.cpp, and recompile. (Note at this point that I can remove the dummy main() from step 5, since there is code inside ManagedWrapper.cpp that implements DllMain().

BUG #5: The compiler fails with the following error

ManagedWrapper.cpp(46) : fatal error C1010: unexpected end of file while looking for precompiled header directiv

9. Add #include "stdafx.h" to the top of ManagedWrapper.cpp and recompile

10. Run DoomedTester.exe

BUG #6: I receive the following runtime error

Debug Error
Program c:\projects\doomed\debug\DoomedTester.ex
R600
- floating point not loade

At this point, I'm stuck. Is there anything I can do to eliminate this floating-point runtime error?

Thanks very much in advance

Whitney Ke
Software Enginee
Rain Bird Corporatio
http://www.rainbird.com

 

[Guest]

I am reposting this question, because I have not received any response from a Microsoft support engineer. I am an MSDN Universal subscriber; what happened to the "guaranteed" 48-hour response?

Whitney Ke
Software Enginee
Rain Bird Corporatio
http://www.rainbird.co

----- wmkew wrote: ----

Hello everyone

I'm encountering a R6002 Runtime error and several bugs when trying to generate a simple Managed C++ application with .NET 2003. The main problem seems to arise from linking with LIBCMT(D).DLL. (My requirement is that we can't link with MSVCRT(D).LIB.) Below are steps I've followed, and the resulting problems

1. Using the New Project wizard, generate a Visual C++ .NET Class Library project (call it "Doomed") and a VC++ .NET Console Application as a tester (call it "DoomedTester") for the Class Library project. Compile both

BUG #1: When compiling the Doomed class library project, the linker yields the following warning

nochkclr.obj : warning LNK4099: PDB 'libc.pdb' was not found with 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib\nochkclr.obj' or at 'C:\Projects\Doomed\Debug\libc.pdb'; linking object as if no debug inf

2. Add the following code to Doomed.h inside Doomed::Class1

file: Doomed.
-------------
// Doomed.

#pragma onc

using namespace System

namespace Doome

public __gc class Class

public: // Add thi
static void f(); // Add thi
}


3. Add the following code to Doomed.cpp and recompile

file: Doomed.cp
---------------
// This is the main DLL file

#include "stdafx.h
#include <cstdio> // Add thi
#include "Doomed.h

// Add the following code
namespace Doome

void Class1::f(

printf("%f", 1.0)



4. The linker can't resolve printf(), so add LIBCMTD.LIB to Linker->Input->Additional Dependencies, and relink

BUG #2: The linker returns with the following error

LIBCMTD.LIB(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function _mainCRTStartu

(Note: This could be resolved by linking with MSVCRTD.LIB instead, but this isn't what I want to do.

5. Add the dummy code "int main() {}" to Doomed.cpp and rebuild, which resolves the above linker error

BUG #3: The compiler didn't notice that my dummy main() isn't returning a value

6. Add the following code to DoomedTester.cpp and rebuild

file: DoomedTester.cp
---------------------
// This is the main project file for VC++ application project
// generated using an Application Wizard

#include "stdafx.h

#using <mscorlib.dll
#using <Doomed.dll> // Add thi
using namespace System

int _tmain(

Doomed::Class1::f(); // Add thi
return 0


7. Run DoomedTester.exe

BUG #4: I get the following exception

An unhandled exception of type 'System.StackOverflowException' occurred in doomed.dl

(Note: Again, this could be resolved by linking with MSVCRTD.LIB instead, but this isn't what I want to do.

8. From MS KB article 814472 (http://support.microsoft.com/?id=814472), follow the "Modify DLL That Contains Consumers That Use Managed Code and DLL Exports or Managed Entry Points" discussion and add ManagedWrapper.cpp to the Doomed project, and add the appropriate calling code to DoomedTester.cpp, and recompile. (Note at this point that I can remove the dummy main() from step 5, since there is code inside ManagedWrapper.cpp that implements DllMain().

BUG #5: The compiler fails with the following error:

ManagedWrapper.cpp(46) : fatal error C1010: unexpected end of file while looking for precompiled header directive

9. Add #include "stdafx.h" to the top of ManagedWrapper.cpp and recompile.

10. Run DoomedTester.exe.

BUG #6: I receive the following runtime error:

Debug Error!
Program c:\projects\doomed\debug\DoomedTester.exe
R6002
- floating point not loaded


At this point, I'm stuck. Is there anything I can do to eliminate this floating-point runtime error??

Thanks very much in advance,

Whitney Kew
Software Engineer
Rain Bird Corporation
http://www.rainbird.com

 

[Carl Daniel [VC++ MVP]]

I am reposting this question, because I have not received any
response from a Microsoft support engineer. I am an MSDN Universal
subscriber; what happened to the "guaranteed" 48-hour response??

This doesn't answer your original question but ... in regard to the
guaranteed response time for MSDN subscribers, you need to post using an
email address that's known to MSDN. Since you're posting as
(e-mail address removed), you're not recognized as being an MSDN
subscriber. Note that you don't need to post with your real email address -
you can register an email alias (which doesn't need to be a real email
address at all), by going to:

http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp&SD=msdn

-cd

 

[Carl Daniel [VC++ MVP]]

Hello everyone,

I'm encountering a R6002 Runtime error and several bugs when trying
to generate a simple Managed C++ application with .NET 2003. The
main problem seems to arise from linking with LIBCMT(D).DLL. (My
requirement is that we can't link with MSVCRT(D).LIB.)

I'm not an expert on MC++, but I seem to recall reading somewhere that you
MUST use the DLL runtime library with MC++. Unfortunately, when I tried to
look up that tidbit of information, I was unable to find it anywhere.

Why is using the DLL CRT not an option for you?

-cd

 

[Guest]

Hi Carl

Thanks for your answer to my question regarding MSDN - I think I understand how to do it now....

Whitne

 

[Guest]

----- Carl Daniel [VC++ MVP] wrote: ----

wmkew wrote

Hello everyone
to generate a simple Managed C++ application with .NET 2003. Th
main problem seems to arise from linking with LIBCMT(D).DLL. (M
requirement is that we can't link with MSVCRT(D).LIB.

I'm not an expert on MC++, but I seem to recall reading somewhere that yo
MUST use the DLL runtime library with MC++. Unfortunately, when I tried t
look up that tidbit of information, I was unable to find it anywhere

Why is using the DLL CRT not an option for you

-c


Carl

Thanks for your response! I wonder if what you said regarding having to use the dynamic CRT with MC++ is true?! Well, what we're trying to do is to avoid potential DLL Hell with the CRT DLL, since we have to support multiple Windows OSes. That's the reason that we originally wanted to link with the static CRT. We don't want any unpleasant surprises if there's a different version of MSVCRT.DLL on a particular machine from the version with which we did our development. We're working around the static CRT issues by indeed linking with the CRT DLL, but because of that, we were planning to deliver MSVCRT.DLL with our product and place it in our product's current directory

Any thoughts
Whitney Ke
Software Enginee
Rain Bird Corporatio
http://www.rainbird.com

 

[Carl Daniel [VC++ MVP]]

Thanks for your response! I wonder if what you said regarding having
to use the dynamic CRT with MC++ is true?! Well, what we're trying
to do is to avoid potential DLL Hell with the CRT DLL, since we have
to support multiple Windows OSes. That's the reason that we
originally wanted to link with the static CRT. We don't want any
unpleasant surprises if there's a different version of MSVCRT.DLL on
a particular machine from the version with which we did our
development. We're working around the static CRT issues by indeed
linking with the CRT DLL, but because of that, we were planning to
deliver MSVCRT.DLL with our product and place it in our product's
current directory.

Actually, that issue isn't too bad anymore since VC7{.1} doesn't use
MSVCRT.DLL (rather, MSVCR70.DLL or MSVCR71.DLL). Placing the CRT dll in
your application's directory is the recommended deployment strategy. Unlike
MSVCRT.DLL, which exists in 23 versions on different versions of windows,
there is only a single version MSVCR70.DLL (likewise a single version of
MSVCR71.DLL).

-cd

 

[Guest]

----- Carl Daniel [VC++ MVP] wrote: ----

wmkew wrote

Thanks for your response! I wonder if what you said regarding havin
to use the dynamic CRT with MC++ is true?! Well, what we're tryin
to do is to avoid potential DLL Hell with the CRT DLL, since we hav
to support multiple Windows OSes. That's the reason that w
originally wanted to link with the static CRT. We don't want an
unpleasant surprises if there's a different version of MSVCRT.DLL o
a particular machine from the version with which we did ou
development. We're working around the static CRT issues by indee
linking with the CRT DLL, but because of that, we were planning t
deliver MSVCRT.DLL with our product and place it in our product'
current directory

Actually, that issue isn't too bad anymore since VC7{.1} doesn't us
MSVCRT.DLL (rather, MSVCR70.DLL or MSVCR71.DLL). Placing the CRT dll i
your application's directory is the recommended deployment strategy. Unlik
MSVCRT.DLL, which exists in 23 versions on different versions of windows
there is only a single version MSVCR70.DLL (likewise a single version o
MSVCR71.DLL)

-c

Interesting. Could one of the Microsoft support engineers please weigh in on this topic? I'd like to know for certain if in fact I can't use the static CRT with MC++.