Compiler bug creating a module with Visual C++

[Peter Ross]

I get a link error when I try and create a module of the following
very simple managed C++ code. I can't imagine a more minimum piece of
code, so I imagine that this is some sort of compiler bug.

#using <mscorlib.dll>
__gc public class Test : public System::Object
{
};

$ cl /clr:noAssembly /LD test.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 13.10.3077 for .NET
Framework
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.dll
/noentry
/noassembly
/dll
/implib:test.lib
test.obj
LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
referenced in function _mainCRTStartup
test.dll : fatal error LNK1120: 1 unresolved externals

 

[Girish Bharadwaj]

That does not look like a bug. Since you are asking it to create a
executable, it could not find an entry point. If you do the same in C# ..
using System;
public class Test {
}

and compile this, it will complain about "no entry point".

This is just complaining in C++ speak.

 

[Girish Bharadwaj]

Doh! I did not read the complete message. It does not seem to make sense
since you are passing /noentry.. why is it complaining..
sorry. ignore my last post.

 

[Girish Bharadwaj]

BTW: the same code compiles just fine on a .NET 1.0.

cl /clr:noAssembly /LD empty.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 13.00.9466 for .NET
Framework
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

empty.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.

/out:empty.dll
/noentry
/noassembly
/dll
/implib:empty.lib
empty.obj


I guess you are right. This probably is something funky with the .NET 1.1 ..

 

[Tomas Restrepo \(MVP\)]

Hi Peter,

I get a link error when I try and create a module of the following
very simple managed C++ code. I can't imagine a more minimum piece of
code, so I imagine that this is some sort of compiler bug.

#using <mscorlib.dll>
__gc public class Test : public System::Object
{
};

Not at all. You're running against the changes made to the compiler/linker
to minimize the Loader-Lock problem (a module is esentially a dll, and will
be subject to the same problems).

To get around it, just link with nochkclr.obj:
cl /clr:noAssembly /LD test.cpp nockclr.obj

 

[Peter Ross]

Hi Peter,


Not at all. You're running against the changes made to the compiler/linker
to minimize the Loader-Lock problem (a module is esentially a dll, and will
be subject to the same problems).

To get around it, just link with nochkclr.obj:
cl /clr:noAssembly /LD test.cpp nockclr.obj

Thank you Tomas that did solve the problem.

I had seen some KB articles about the Loader-Lock problem, but
couldn't relate it directly to my problem.

Could you point me to a resource which mentions nochkclr.obj? I am
interested to see why I didn't work it out.

Regards,
Peter

 

[Tomas Restrepo \(MVP\)]

Hi Peter,

Thank you Tomas that did solve the problem.

I had seen some KB articles about the Loader-Lock problem, but
couldn't relate it directly to my problem.

It was a logical conclusion for me, since modules are usually linked into an
assembly, typically a DLL one (and not an EXE).

Could you point me to a resource which mentions nochkclr.obj? I am
interested to see why I didn't work it out.

Humm... let me see... I believe the documentation mentions it... See [1] and
[2]

[1]
http://msdn.microsoft.com/library/d.../vccore/html/vcerrlinkertoolserrorlnk2019.asp
[2]
http://msdn.microsoft.com/library/e...tsfrompureintermediatelanguagetomixedmode.asp