Missing Ordinal From MFC42.DLL

[M J]

Hi there.

I used Win98 to develop an application that should also run on NT. I tested it on an NT box and it said that the MFC42.DLL was missing an ordinal, and therefore refused to run. When I updated the MFC42.DLL file on the NT box, the app ran just fine.

My question: how can I avoid making the user update the MFC42.DLL? I thought perhaps if I changed my compile option to use MFC in a static library this would fix things, but then I got the following link errors and couldn't compile:

nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMT.lib(new.obj)
nafxcw.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMT.lib(delete.obj)
Release/MyApp.exe : fatal error LNK1169: one or more multiply defined symbols found

Is the solution to use static MFC? If so, how do I fix these link errors? Or is there a better solution to the problem? I've never used InstallShield, but should I package an updated version of MFC42.DLL with my program using this utility?

Thanks in advance for your help!

Mike

[M J]

Hi there.

I used Win98 to develop an application that should also run on NT. I tested it on an NT box and it said that the MFC42.DLL was missing an ordinal, and therefore refused to run. When I updated the MFC42.DLL file on the NT box, the app ran just fine.

My question: how can I avoid making the user update the MFC42.DLL? I thought perhaps if I changed my compile option to use MFC in a static library this would fix things, but then I got the following link errors and couldn't compile:

nafxcw.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMT.lib(new.obj)
nafxcw.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMT.lib(delete.obj)
Release/MyApp.exe : fatal error LNK1169: one or more multiply defined symbols found

Is the solution to use static MFC? If so, how do I fix these link errors? Or is there a better solution to the problem? I've never used InstallShield, but should I package an updated version of MFC42.DLL with my program using this utility?

Thanks in advance for your help!

Mike

[M J]

No ideas?

[M J]

No ideas?

[WillCodeForMoney]

The problem is because of different versions of the DLLs. You executable links with an import library (.LIB) associated with each DLL. The import library that you executable links with must be of the same version as the associated DLL on the target machine that the exe will run on.

The best solution is to link statically. The link errors can be due to a number of problems.

The usual suspects:

Different dependencies are built with different link options. That is, one lib or dll is linking to MFC and/or CRT dynamically while another lib or DLL is linking statically.

You have to be careful when delivering DLLs to another system. If you deliver versions that are incompatible with other libs on the target system you can break other software.

WillCodeForMoney

[WillCodeForMoney]

By the way, you can deliver DLLs with InstallShield (as long as you deliver the correct ones that Microsoft ok's for redistribution). Just don't deliver them to their usual location. Make sure they are loaded from the app's directory.


WillCodeForMoney

[M J]

Thank you, "Will". That gives me some ideas about how I can go about fixing my linking problem when compiling statically. I link some files that do not use MFC at all, and perhaps the problem is there. I appreciate the suggestions.

Mike

[M J]

Thank you, "Will". That gives me some ideas about how I can go about fixing my linking problem when compiling statically. I link some files that do not use MFC at all, and perhaps the problem is there. I appreciate the suggestions.

Mike

[M J]

Well, I thought that I had some ideas for how to fix the statically-linked-version errors. But it looks like my project settings force me to use MFC exclusively as a shared dll or as a statically linked library for the entire project, so there's no way that my non-MFC classes can be controlled individually on that level. Also, it appears that both debug and release versions use only the multithreaded DLL for runtime library and not some mixture of runtime libraries. I'm not sure how to proceed, but I guess I'll keep plugging away at changing the project settings until the link errors go away.

[M J]

Well, I thought that I had some ideas for how to fix the statically-linked-version errors. But it looks like my project settings force me to use MFC exclusively as a shared dll or as a statically linked library for the entire project, so there's no way that my non-MFC classes can be controlled individually on that level. Also, it appears that both debug and release versions use only the multithreaded DLL for runtime library and not some mixture of runtime libraries. I'm not sure how to proceed, but I guess I'll keep plugging away at changing the project settings until the link errors go away.

[M J]

Because I want to change my project that was AppWizarded as a "Use MFC as a Shared DLL" to static MFC link, should I just be able to change that in the Project Settings for All Configurations? Or is it much more involved than that? Starting over from AppWizard may be a daunting task as I've used ClassWizard to make many customizations.

[M J]

Because I want to change my project that was AppWizarded as a "Use MFC as a Shared DLL" to static MFC link, should I just be able to change that in the Project Settings for All Configurations? Or is it much more involved than that? Starting over from AppWizard may be a daunting task as I've used ClassWizard to make many customizations.

[Paul McKenzie]

There is a bug in VC++ when attempting to build a static library version that crops up from time to time.

Before doing anything, make sure that all of your modules are linked using the same run-time library. This includes all of your source files, as well as *any* external static or import libraries that you may have added from a third-party. I noticed that if you use a .LIB file that was built using a different run-time library, linking will fail.

If you are OK with the above, the fix to this problem is a little drastic, but hopefully not too much. The bug in VC++ is that sometimes a build of a static library introduces components to the linker that use the incorrect run-time library. I found this out the hard way -- for a whole day I was trying to build a static version of a program, and the linker was giving me the same or similar errors to what you are seeing. All of the settings were OK, so I said to heck with this and just removed all the .CPP files from my project and compiled/linked one by one. Eventually, the linker cooperated when I added back the last file.

So you need to rebuild from scratch. Not just do a "Rebuild All", but remove all of your .CPP files from your project. Next, you add them in one at a time, compiling and attempting to link each time. You will notice that you will not be getting the same linker errors -- instead you will be getting the more familiar "function not found" error, since all of your CPP files are not in the project.

When you've added the last file, hopefully the linker will cooperate and link successfully.

Regards,

Paul McKenzie

[M J]

Thanks very much, Paul. I tried that technique and it worked -- no more link errors after converting to a static build. Your experience saved me a lot of time, as I probably never would've tried that route.

Thanks again!

Mike

[M J]

Thanks very much, Paul. I tried that technique and it worked -- no more link errors after converting to a static build. Your experience saved me a lot of time, as I probably never would've tried that route.

Thanks again!

Mike