Skip to main content
gamedev.net
🔒 Locked

Compiling with VS.net 2003 C++

Started by BloodLust666 Jun 2, 2006 at 7:29 PM 16 replies 1.1k views
Original Post
BloodLust666
BloodLust666
I made a program that uses OpenGL, OpenIL, and SDL, but on some computers it either says "failed to initialize" or "missing MSVCP71D.dll"; i was wondering if there's a way to compile all the dll's and whatnot inside the exe so no one has to load or install anything before being able to run my program.
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
Inside project properties there's a setting that allows you to link MFC using a static library. I don't have VS2003 on this computer but I'm pretty sure it isn't hidden very deeply.
Xai
Xai
first of all, the D is debug, you can only ship install release builds on non-development computers ...
BloodLust666
BloodLust666
it is on release mode..
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
BloodLust666
BloodLust666
after setting to make it a static library, i'm getting these errors:

Particle System error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
Particle System error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj)
Particle System error LNK2005: __isctype already defined in LIBCMTD.lib(isctype.obj)
Particle System error LNK2005: _exit already defined in LIBCMTD.lib(crt0dat.obj)
Particle System error LNK2005: _fclose already defined in LIBCMTD.lib(fclose.obj)
Particle System error LNK2005: _strncpy already defined in LIBCMTD.lib(strncpy.obj)
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
Looks like it's still using debug libraries. If you were just doing a build, try rebuilding the entire project.
BloodLust666
BloodLust666
that's not working... but i found in the C++ > preprocessor i have "NDEBUG", should i get rid of that?
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
Whoops, MSVCP is the C-Runtime library, not MFC, read a little to quickly. Not sure if the "Statically Link MFC" option actually turns this switch on, but you should turn on the /MD/MT [EDIT: See below] compiler switch. Here's more details: Link

Sorry my anwsers are a little crummy, I only have VS2003 at work so I can't double check anything while I'm at home.

[Edited by - perfectly_dark on June 2, 2006 10:46:08 PM]
BloodLust666
BloodLust666
alright, that worked, now how would i get rid of these warnings:

d:\Stuff\Visual Studio Projects\Particle System\Utility.h(117): warning C4239: nonstandard extension used : 'argument' : conversion from 'Wrath2D::cWUtility::sWVector2D' to 'Wrath2D::cWUtility::sWVector2D &'
D:\Program Files\Visual Studio .Net 2003\Vc7\PlatformSDK\Include\WinDef.h(216): warning C4562: fully prototyped functions are required with the '/clr' option: converting '()' to '(void)'
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
Sorry, you should be using the /MT switch to statically link, /MD links with DLLs. Following the link on the page I gave above explains that you can't use the /clr switch with a statically linked C Runtime Lib.

Quote:

If you are using the /clr compiler switch, your code will be linked with an import library, msvcmrt.lib. The import library references a new library, msvcm80.dll, which provides a proxy between your managed code and the native CRT. You cannot use the statically linked CRT ( /MT or /MTd options) with /clr. Use the dynamically-linked libraries (/MD or /MDd) instead
BloodLust666
BloodLust666
compiling with /MT causes that errors from the beginning again..
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
Yes, that's because you can't statically link the C Runtime when using CLR, you'll have to dynamically link and redistribute the dll files.

<a href="http://msdn2.microsoft.com/en-us/abx4dbyh.aspx>Link
BloodLust666
BloodLust666
i don't really know much about that compiler.. haven't really messed with it much, so i have no idea what you meant in that last post lol sorry..
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
CLR is the Common Language Runtime, it's used when you create a Managed C++ (.NET) project. That's what the /clr compiler option specifies, a CLR project. The C Runtime Library provides C language features. When you link statically with a library, it is compiled into the EXE file. If you link dynamically, the program will load the library from a dll at run time. If that dll cannot be found then you'll get an error message like "missing xxxx.dll".

What I was trying to tell you in the last post is that if you're using the /clr option (Managed C++), then you cannot compile a project with a statically linked C Runtime Library, you have to use a dynamically link to the C Runtime Library (the /MD option). When you dynamically link you use a dll and give it to whoever runs your program.

Hope that helps
BloodLust666
BloodLust666
ohhh, alright thanks; that clears that up.. but how do i get rid of those warnings? or do i just have to live those with those?

also, if i wanted to statically link the libraries, what would i have to do to the compiler options?
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
perfectly_dark
perfectly_dark
If you want to statically link a project you would use the /MT option but no /clr option. However, if you disable CLR (AFAIK), you wont be able to compile a Managed C++ application. I don't know if you're using Managed C++, but if you are than it looks like you're stuck with the dynamically linked runtime.

I don't know about the warnings, the second one appears to be in an SDK file so I wouldn't modify any of that code. You may want to wrap any #include that references that file with the following:

#pragma warning( push )#pragma warning( disable : 4562 )#include <WinDef.h>   //Or some file that includes WinDef.h#pragma warning( pop )


This will silence the specific warning inbetween the push/pop pragmas.

As for the other warning, I don't know what it is. A quick look at MSDN gave the following description: Link

BloodLust666
BloodLust666
nah, i'm not using managed. How do i turn off that /clr? i was looking all over and couldn't find it..
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML
BloodLust666
BloodLust666
i was looking through the help on how to turn it off but the setting it said to turn off wasn't there..
-------------------------Unless specified otherwise, my questions pertain:Windows Platform (with the mindset to keep things multi-platform as possible)C++Visual Studio 2008OpenGL with SFML

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.