VCMAME: compiles with VC2003, fails with VC2005

I'm trying to build the MAME source using Visual C++ 2005.

I'm using the VCMAME project files from http://www.vcmame.net/ .
I first built the project in Visual Studio 2003, then opened the project in VC++ 2005 and rebuilt.

I only had to make a few modifications to the project, like adding _CRT_SECURE_NO_DEPRECATE to silence a bunch of warnings.

However, one of the source files (winalloc.c) implements their own memory handling functions so that memory leaks and other bugs can be tracked and diagnosed. This used to build properly with Visual Studio 2003, however in 2005, the compile fails at the linker stage with this...

LIBCMT.lib(calloc.obj) : error LNK2005: _calloc already defined in winalloc.obj
LIBCMT.lib(realloc.obj) : error LNK2005: _realloc already defined in winalloc.obj

If I link with the multi-threaded debug library instead, I get this...

LIBCMTD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in winalloc.obj
LIBCMTD.lib(dbgheap.obj) : error LNK2005: _calloc already defined in winalloc.obj
LIBCMTD.lib(dbgheap.obj) : error LNK2005: _realloc already defined in winalloc.obj
LIBCMTD.lib(dbgheap.obj) : error LNK2005: _free already defined in winalloc.obj
LIBCMTD.lib(dbgheap.obj) : error LNK2005: __msize already defined in winalloc.obj

I'm at a loss about what to do to fix this. If I don't link against one of the C runtime libraries, then I get thousands of undefined symbols while linking.

Any help or advice to solve this problem will be greatly appreciated.

Answer this question

VCMAME: compiles with VC2003, fails with VC2005

Echo10
Ok, I've tried everything I can think of to make this link. I'm fairly certain that you have identified the problem. However, nothing I do makes a difference. Is it possible that one of the libraries in my project is linking with LIBCMTD.lib first and then my linking with it later is causing the problem

I'm about ready to give up at this point.
DataCorrupt
Could you please report a bug at the product feedback center at http://lab.msdn.microsoft.com/productfeedback/default.aspx. Please include in the bug details all compiler flags used a repro case exhibiting the issue. We would be extremely interested in taking a look into the issue.

Thanks,
Ayman Shoukry
VC++ Team
blkeller
Not to throw more fuel on the fire but just for the hell of it, I tried building a release build last night using the /FORCE:MULTIPLE linker switch and the compiler now stops with a fatal internal compiler error...

6>c:\@mame\vcmame0100\src\cpu\nec\nec.c(575) : fatal error C1001: An internal error has occurred in the compiler.
6>(compiler file 'f:\rtm\vctools\compiler\utc\src\P2\main.c[0x10BF1EF2:0x0000001C]', line 182)
6> To work around this problem, try simplifying or changing the program near the locations listed above.
StephaneB
Hi Again:

This is to let you know that I have reproduced the problem. I will post more as soon as I know something.

Best Regards,

Bernard C

Brian_Kramer wrote:

I'm curious why the compiler is giving an ICE due to a linker flag. Do you have Whole Program Optimization (/GL) turned on by any chance That's the only scenario I know of where the linker calls the compiler.

It's not. I didn't make myself clear in my post. Up to this point, I had never tried a release build because I couldn't get past the linker problem in the debug build. Since /FORCE:MULTIPLE let me finish the debug compile, I added /FORCE:MULTIPLE to the release build,tried compiling, and got the ICE.

I'm sure that the ICE would occur with or without the flag.

AEnglish
Rick Troemel MS wrote:
Hi Again:

This is to let you know that I have reproduced the problem. I will post more as soon as I know something.

Thanks for looking at this for me. I really appreciate it.

I'm not sure if this will help but I found a post on a board where people were trying to compile some Quake code or something and ran into the same problem...

http://www.chatbear.com/board.plm a=viewthread&b=4991&t=104,1102070328,6443&s=0&id=741971

Their solution was to add "/FORCE:MULTIPLE" to the linker command line to force the link even though there was a conflict.

I suppose if you combined the above with supressing compiler warnings 4006 and 4088, at least you could *hide* the problem. But that's sort of a hack. There's really no reason that it shouldn't build properly on 2005 if it builds on 2003.

Incidentally, I was at the Microsoft Launch Tour in Philly today. I went to the "Ask the Experts Q&A" for Visual Studio and asked about this linking problem. The guy I spoke to said that he had no idea and that nobody that was there that day probably would either. He said that his days of fighting with C++ and linker problems are far behind him and we laughed.

Thanks again,
Bill
trianta99
I'm curious why the compiler is giving an ICE due to a linker flag. Do you have Whole Program Optimization (/GL) turned on by any chance That's the only scenario I know of where the linker calls the compiler.

If you can provide a reproducable case (under VS 2005 Beta 2 or RTM) that can be zipped up with instructions, you should submit a bug report on this.

Brian
maui_desu
Hi -- I am having the same problem as the OP and am curious to hear what you come up with!
gls
HI:

I have the zipfile you posted, but haven't had the chance to look it over yet. Stay tuned - I'll post an answer as soon as I know something.
Coretta
VCMAME is a project that overlays the standard MAME source.

The project is building an EXE statically linking in the C runtime libraries.

Here's a link to a zip containing my project...

http://files.3feetunder.com/vcmame0100.zip (12.0MB)

Note that there is a custom build step that requires NASM.

I've included the latest version of NASM with my project linked above.

The archive is named nasm-0.98.39-win32.zip. Just unzip it into a folder somewhere (something like C:\Program Files\nasm) and then add that folder to the Visual C++ 2005 Tools path...

Tools -> Options -> Projects and Solutions -> VC++ Directories -> Executable Files

... so the project can find NASM while compiling.
ascanio

Hi:

I am installing the DirectX SDK in order to attempt to build the project. It occurs to me that you may be able to find the conflict in the interim by adding "/verbose" to your linker switch. This may help you pinpoint where it is finding the conflicting functions.

Let me know and I'll try this out again in the morning after I get the SDK on my machine.
Terry Rossow
Hi Bill:

Unfortunately, I have not come up with an answer to your lnk2005 problem yet. I will look over the other thread you mentioned. I usually don't like trying /FORCE anything with the linker - it is dangerous <g> and shouldn't be necessary.

I plan to talk with our linker devs today to see if I can get some help with how to get this to link.

I was planning to post a message this morning about the ICE's, which I also ran into yesterday. I realized you probably had only built debug up to this point. I ran into the same ICE on 2 files, nec.c and i86.c. They are both caused by a bug in the expression optimizer and I have already reported the bug via our internal database. As for how to get around them, the best I can offer for now is to disable optimizations for the two functions in question.

The first ICE occurs in C:\VCMAME\src\cpu\nec\nec. Here the offending function is called i_pushf. Around line 575 of the file, do the following to disable optimzation for the one function:
#pragma optimize("",off)
OP( 0x9c, i_pushf     ) { PUSH( CompressFlags() ); CLKS(12,8,3); }
#pragma optimize("",on)

The other occurs in cC:\VCMAME\src\cpu\i86\i86.c, which #includes instr86.c. Here, the function is called i86_pushf, and it is around line 2005 of instr86.c. Using the same trick:
#pragma optimize("",off)
static void PREFIX86(_pushf)(void)    /* Opcode 0x9c */
{
ICOUNT -= cycles.pushf;
#ifdef I286
    PUSH( CompressFlags() | 0xc000 );
#elif defined V20
    PUSH( CompressFlags() | 0xe000 );
#else
    PUSH( CompressFlags() | 0xf000 );
#endif
}
#pragma optimize("",on)

If you would rather not edit source code, simply changing the /O switch for nec.c and i86.c to /Od will also workaround the bug.

I hope to have an answer for you soon about the lnk2005 - hang in there.
boris_skarbo
Well Bill, you came to the right place now. We are here to solve such linker and C++ challenges :-)

I have seen such issues before if you try to include in your solution libs that were built using older compilers (VC2003) with older CRT model. If that is the case, rebuilding the lib with the new compiler (VC2005) should fix the issue.

I haven't looked into the repro though but I believe Rick is going to post the results of his investigations once he is done.

Thanks for your patience.

Thanks,
Ayman Shoukry
VC++ Team
Jay1980_UK

Hi:

There are several different versions of the VCMAME project at the webpage you mentioned, but none of them seem to include ...\src\windows\winalloc.c, which is referenced by the vcmame project (several others seem to be missing as well). Please advise WHICH vcmame .zip file from the web page contains the full project.

In general, you should be able to override CRT functions by means of WEAK EXTERNALS. See http://support.microsoft.com/default.aspx scid=kb;en-us;148652 for an article about this kind of problem with MFC, where some of the CRT memory alloction functions are overriden. In MFC's case, it is important to specify the MFC lib containing the overriden CRT functions before the CRT lib on the link line. This is accomplished by specifying /NOD:libcmt{d}.lib (or /NOD:msvcrt{d}.lib), then explicitly adding the /NOD lib to the link line AFTER the MFC lib.

I am unable to tell what the VCMAME project is building (a dll a static lib ). The point is that you may need to do something similar here - that is add /NOD:libcmt{d}.lib to your link line, followed by the .lib (or stub lib) that VCMAME is building, THEN the CRT lib you are linking with.

Hope This helps,
VCMAME: compiles with VC2003, fails with VC2005

Answer this question