1

I'm trying to compile a C program (specifically, the Python interpreter) as a plain statically linked 64-bit Windows binary. My command line looks like this:

cl /DPy_BUILD_CORE ... /link Advapi32.lib Shell32.lib User32.lib

where ... is the long list of source files and include directory specifications, and the library specifications I added as necessary to fix unresolved symbol errors. I'm now getting this error:

LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup

You might think this question has been asked before, but in this case main is spelled without a leading _ - something that doesn't happen in any of the other occurrences I could find with a Google search. Just to be sure, I tried writing a minimal main() function and throwing it in, and that still gave the above error plus a duplicate symbol warning, so that's not what's missing.

Any idea what's wrong here?

rwallace
  • 31,405
  • 40
  • 123
  • 242
  • 1
    Are you trying to build a console app? I see no `/SUBSYSTEM`in your compilation line. And what calling convention are you using? I'd start with those. – WhozCraig Jan 20 '14 at 10:28
  • @WhozCraig Yes. I haven't come across /subsystem before, and cl says it's never heard of it; what's the reference? The command line I'm using looks like the one that normally works for building command line programs, including the default calling convention; I'm not aware of any way for the contents of a .c file to break the calling convention between the standard library and a different .c file? – rwallace Jan 20 '14 at 10:34
  • 1
    As you asked, [see /SUBSYSTEM](http://msdn.microsoft.com/en-us/library/fcc1zstk.aspx) on ms' site. Its a linker option. The calling convention is a compiler option (though its exact syntax escapes me; sry). – WhozCraig Jan 20 '14 at 10:43
  • @WhozCraig ah, thanks! The default is console, which is what I want, but I tried specifying it explicitly just to make sure, and the error is unchanged. I remember calling convention used to be an issue, but that was many years ago, and the current version of the compiler indeed doesn't say anything about it in its list of options. – rwallace Jan 20 '14 at 10:51

2 Answers2

0

You trying compile it like application with entry point (not static linked library).

Defter
  • 214
  • 1
  • 7
  • Yes exactly - I'm trying to compile it as a (standalone .exe) program, not as a library. – rwallace Jan 20 '14 at 10:30
  • 1
    Maybe OP wants to make an EXE with all dependencies statically linked – manuell Jan 20 '14 at 10:33
  • What is your project type? If it's a "Win32 project", your entry point should be (w)WinMain. If it's a "Win32 Console Project", then it should be (w)main. The name _tmain is #defined to be either main or wmain depending on whether UNICODE is defined or not. If it's a DLL, then DllMain. – Defter Jan 20 '14 at 10:34
  • int _tmain(int argc, _TCHAR* argv[]) – Defter Jan 20 '14 at 10:34
  • 1
    @Defter I'm not using the IDE at all, I'm calling the compiler from the command line. – rwallace Jan 20 '14 at 10:36
  • from command line you can specify type too or compiler be used default type – Defter Jan 20 '14 at 10:37
  • @Defter It is set to link for console. I tried providing wmain instead of main just in case, but no difference. – rwallace Jan 20 '14 at 11:50
0

From Jeremy Kloth on the python-win32 mailing list:

The list of files also needs "..\Modules\python.c" to create an executable. (tested with VS2008 for x64).

That lack of leading underscore comes from how symbols are exported in 64-bit PEs vs. 32-bit PEs. That is, 64-bit PEs do not prepend an underscore to exported symbols.

rwallace
  • 31,405
  • 40
  • 123
  • 242