LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup when building a DLL

SDL Development
1

NB: I originally posted this on StackOverflow but people told me to post it to the
mailing list, so here we go. Link to original post:

So here’s another thread about the infamous ___tmainCRTStartup unresolved external
symbol. Yes, it’s about SDL again, but it’s with a twist which AFAICS hasn’t been
covered here yet. Let me first clear up some parameters:

  1. I am trying to build a DLL that statically links against SDL2.lib.

  2. I am not using Visual Studio but Visual C and a console (first cmake, then nmake).

  3. The project is entirely in C, no C++ code is in there (unless there’s C++ in SDL2
    but AFAIK SDL2 is completely in C)

  4. All objects that are collected in SDL2.lib and the other objects are compiled
    using /MT, i.e. I want to link statically against the Visual C runtime (libcmt.lib).

  5. SDL2.lib is then created like this:

link /lib /out:SDL2.lib file1.obj file2.obj…

  1. The target DLL is linked like this:

link /dll /subsystem:WINDOWS /out:test.dll file1.obj file2.obj … kernel32.lib user32.lib gdi32.lib shell32.lib ole32.lib
oleaut32.lib imm32.lib winmm.lib version.lib SDL2.lib

What is confusing the hell out of me here is that the call above yields the following error:

LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

How can this possibly happen? I clearly pass /dll to link.exe so why on earth is the C runtime
looking for main()? It should be looking for DllMain()! A main() symbol in a DLL doesn’t make
any sense at all, yet I get this confusing error!

It must be something inside SDL2.lib that is causing this problem but I honestly have no
clue what could force the linker to look for a main() entry point here. I mean, SDL2.lib
is a linker library that should be completely target neutral, i.e. it should be possible
to link SDL2.lib against a WinMain() executable but it should also be possible to link
SDL2.lib against a DllMain() library but here it seems to refuse to be linked into a DLL!

Does anybody have an idea what could be wrong here? I have searched for hours now and this
totally escapes me.

Side note #1: Interestingly, the problem does not occur when everything is compiled
using /MD. It only occurs when using /MT. I’m really completely clueless as to what could
be the cause here.

Side note #2: I’ve also tried to compile SDL2 with /DSDL_MAIN_HANDLED but it doesn’t make
the error go away.

Thanks for any help!

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

2

Hi,

Could it be possible that a #pragma directive somewhere is changing the
entry point of your program.

To force the entry point to be ‘main’ the following could be used:

#pragma comment(linker,"/ENTRY:mainCRTStartup")

If you were to search for it in your code base perhaps its lurking
somewhere.

See here for more of this #pragma stuff:

http://www.flipcode.com/archives/Win32_ConsoleWindowed_Tip.shtml

Thanks,
AidanOn 05/08/2014 11:09, Andreas Falkenhahn wrote:

NB: I originally posted this on StackOverflow but people told me to post it to the
mailing list, so here we go. Link to original post:
http://stackoverflow.com/questions/25067151/lnk2019-unresolved-external-symbol-main-referenced-in-function-tmaincrtstar

So here’s another thread about the infamous ___tmainCRTStartup unresolved external
symbol. Yes, it’s about SDL again, but it’s with a twist which AFAICS hasn’t been
covered here yet. Let me first clear up some parameters:

  1. I am trying to build a DLL that statically links against SDL2.lib.

  2. I am not using Visual Studio but Visual C and a console (first cmake, then nmake).

  3. The project is entirely in C, no C++ code is in there (unless there’s C++ in SDL2
    but AFAIK SDL2 is completely in C)

  4. All objects that are collected in SDL2.lib and the other objects are compiled
    using /MT, i.e. I want to link statically against the Visual C runtime (libcmt.lib).

  5. SDL2.lib is then created like this:

link /lib /out:SDL2.lib file1.obj file2.obj…

  1. The target DLL is linked like this:

link /dll /subsystem:WINDOWS /out:test.dll file1.obj file2.obj … kernel32.lib user32.lib gdi32.lib shell32.lib ole32.lib
oleaut32.lib imm32.lib winmm.lib version.lib SDL2.lib

What is confusing the hell out of me here is that the call above yields the following error:

LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

How can this possibly happen? I clearly pass /dll to link.exe so why on earth is the C runtime
looking for main()? It should be looking for DllMain()! A main() symbol in a DLL doesn’t make
any sense at all, yet I get this confusing error!

It must be something inside SDL2.lib that is causing this problem but I honestly have no
clue what could force the linker to look for a main() entry point here. I mean, SDL2.lib
is a linker library that should be completely target neutral, i.e. it should be possible
to link SDL2.lib against a WinMain() executable but it should also be possible to link
SDL2.lib against a DllMain() library but here it seems to refuse to be linked into a DLL!

Does anybody have an idea what could be wrong here? I have searched for hours now and this
totally escapes me.

Side note #1: Interestingly, the problem does not occur when everything is compiled
using /MD. It only occurs when using /MT. I’m really completely clueless as to what could
be the cause here.

Side note #2: I’ve also tried to compile SDL2 with /DSDL_MAIN_HANDLED but it doesn’t make
the error go away.

Thanks for any help!