Trouble compiling the PC source

Discussion about other and unofficial ports of ScummVM

Moderator: ScummVM Team

Post Reply
User avatar
dreammaster
ScummVM Developer
Posts: 551
Joined: Fri Nov 04, 2005 2:16 am
Location: San Jose, California, USA

Trouble compiling the PC source

Post by dreammaster »

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.
User avatar
sev
ScummVM Lead
Posts: 2272
Joined: Wed Sep 21, 2005 1:06 pm
Contact:

Post by sev »

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


Eugene
User avatar
dreammaster
ScummVM Developer
Posts: 551
Joined: Fri Nov 04, 2005 2:16 am
Location: San Jose, California, USA

Post by dreammaster »

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
Retired
Posts: 106
Joined: Wed Sep 21, 2005 5:06 am
Location: Perth, Western Australia

Post by Ender »

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 :)
User avatar
Dark-Star
Posts: 150
Joined: Sun Oct 30, 2005 9:36 pm
Location: Reutlingen, GERMANY

Post by Dark-Star »

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
User avatar
dreammaster
ScummVM Developer
Posts: 551
Joined: Fri Nov 04, 2005 2:16 am
Location: San Jose, California, USA

Post by dreammaster »

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.
User avatar
Dark-Star
Posts: 150
Joined: Sun Oct 30, 2005 9:36 pm
Location: Reutlingen, GERMANY

Post by Dark-Star »

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
Post Reply