Trouble compiling the PC source

dreammaster · Post by **dreammaster** » Fri Nov 25, 2005 1:26 pm

I hope this is the correct forum for this. I've spent some time setting up my system so I could compile the ScummVM on my PC using Microsoft Visual Studio 2003 (using the VC7 solution). I've got all the libraries sorted out, but am getting two warnings that concern me:

LINK : warning LNK4098: defaultlib 'LIBCD' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

I'm wondering if this is likely to cause problems. One reason I'm asking is that although, in the compiled application, the menu UI came up, I've already encountered an access violation. I traced it to within a call to fflush(stdout) in main.cpp/debugHelper (which was called by a call to the debug() method).

Thanks for any help.

Post by **sev** » Fri Nov 25, 2005 4:05 pm

It may happen that MSVC project files are out of date.

Eugene

dreammaster · Post by **dreammaster** » Fri Nov 25, 2005 8:29 pm

I noticed that. I had to delete some deprecated files from the project nodes for kyra and saga.

Unfortunately, whilst I'm experienced in C++, I'm not completely famililar with Visual C++, so I'm not sure if this conflict is the cause of the access violation or not, and I'm also not sure how to find out which library they're clashing with or not. I'll have to experiment in the Project Options and see if I can figure out what's causing the conflict.

Ender · Post by **Ender** » Sat Nov 26, 2005 4:03 am

I guess that the multithreaded (libcmt) and debug (libcd) versions of libc are being linked?

If your building release profile, try switching to debug (or the other way around), barring just adding the NODEFAULTLIB:libcd to link options.

This is all just a guess, I haven't used MSVC in... well, since 0.3.0 I think :)

Dark-Star · Post by **Dark-Star** » Mon Nov 28, 2005 11:19 am

I know that problem (segfaults when using something that has to do with file/console I/O)

It has not directly to do with these two libraries.

Try setting the target from "Multithreaded DLL" to "Multithreaded" (or the other way round, depending on how it's currently set up) for all sub-targets.
You find this in the Project properties under "Compiler->Code generation" IIRC.

If you compiled your SDL and/or other libraries yourself, make sure that you match this setting on all the builds, e.g. always use "Multithreaded".

I wouldn't recommend playing a debug build as it might be a lot slower than a release build.

Edit: Just FYI, the setting "Multithreaded" makes VC link in the (thread-safe) C runtime statically into your project, while "Multithreaded DLL" links your project to MSVCRT.DLL, MSVCR71.DLL and/or MSVCP71.dll

dreammaster · Post by **dreammaster** » Thu Dec 01, 2005 12:39 am

Thanks for the suggestion, Dark Star. Unfortunately, it didn't work on any of the settings. On the plus side, though, I've been able to determine that problems only occur on calls to stdout/stderr, such as for warning() or error() messages, so that's good enough for what I want to use ScummVM for.

DreaMaster.

Dark-Star · Post by **Dark-Star** » Thu Dec 01, 2005 5:27 pm

Strange, that was exactly what fixed the problem for me. Did you make sure to "rebuild all"?

Some more background info I've gathered: The DLL build and the static build use different methods of storing the list of open file descriptors. So if you open a file from within a DLL build, it stores that file's descriptor in a different location than where the static build (ScummVM) expects it, so ScummVM reads an invalid memory location -> crash