Forums > Dev

MFC in Max External

July 30, 2013 | 9:10 am

I’m trying to implement some existing code into a Max external which uses MFC. I know that ‘windows.h’ is already included in the Max SDK, and these two aren’t supposed to be used together.

Basically, am I wasting my time on this? I’m including ‘stdafx.h’ first to avoid errors due to use of ‘windows.h’, but am now getting the following error:

error LNK2005:_DllMain@12 already defined in dllmain_win.obj

Is there a fix for this? Will this ever work?


July 31, 2013 | 7:19 am

I’m not an MFC expert, but I understand that it provides some kind of default application framework. And any application framework is going to have a main(). But your external also has a main(). You can’t have two functions named main() (which is what your linker is complaining about).

You may be able to avoid this by carefully selecting what libraries are linked in. Dunno.

Using MFC is likely to kill any chance of cross-platform compatibility, but you presumably don’t care about that.


July 31, 2013 | 8:49 am

MFC provides its own DllMain. The max externals in the SDK also provide their own DllMain. Hence, your external has two and you are getting this error.

The good news is that the DllMain provided in the max sdk samples doesn’t actually do anything except for a small optimization that you probably don’t even want if you are using MFC. So to fix this problem you can probably just remove dllmain_win.c from your project.

Hope that helps,
Rob


July 31, 2013 | 9:02 am

Thanks Rob. I’ve removed dllmain_win.c.

Unfortunately I’m now getting:

error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)


July 31, 2013 | 9:12 am

Interestingly for a release build I instead get:

error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)


July 31, 2013 | 9:18 am

Sounds like the link order is not correct so there is a conflict between MFC and the MS CRT.

Googling the above error brings up plenty of articles that may be helpful for you including this MS KB article:

http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652

But one page suggests this simple fix:

In most cases it its sufficent to place the #include as the first header file that is included in the stdafx.h.

And, once you go to get your release build working I suggest you add this preprocessor flag to your project settings:

#define MAXAPI_USE_MSCRT

This will cause your object to link to the standard microsoft CRT rather than the shared maxcrt.dll that we ship with max. You can see what that switch does by looking in ext_prefix.h.

Rob


July 31, 2013 | 9:20 am

Our posts crossed in the air. You said:

Interestingly for a release build I instead get:

error LNK2005: _DllMain@12 already defined in maxcrt.lib(dllmain.obj)

Yes, my prior post anticipated this. :) Once you add MAXAPI_USE_MSCRT to your project you will get an error more similar to the debug one.

Rob


July 31, 2013 | 9:51 am

OK, this seems like a non-Max related error now. Currently I am including stdafx.h first, so will have to investigate…


July 31, 2013 | 10:09 am

Found a solution on http://binglongx.wordpress.com/2011/07/11/error-lnk2005-_dllmain12-already-defined-in-msvcrt-lib/

Suppress default library for the offending .obj file. Use /Zl for the .cpp file: C/C++ Advanced | Omit Default Library Name – Yes (/Zl). The results in the .obj file without any default library records. Therefore, linker would follow default libraries and their order from other .obj files, and hopefully they are correct in the sense of an MFC application. If the offending .cpp file relies on other default libraries for its own right, if /Zl is used on it, we have to add back explicitly those libraries to linker options.


Viewing 9 posts - 1 through 9 (of 9 total)