Jump to content
  • Advertisement
Sign in to follow this  
Splinter of Chaos

Redistribution hell.

This topic is 3907 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've spent a little less than a month making my game (not that it's finished), and I'm the only one who can play it. I tried following one of the threads on this site: http://www.gamedev.net/community/forums/topic.asp?topic_id=406590, and the problem seems similar, but it didn't seem to have ever gotten resolved. I have tried including all the necessary dll files, but every time I included one, windows asked for another, like a mother who's never satisfied. I've gone to college, got a job, a wife, a family, what next? Oh, how could I have forgotten to get a dog? The last thing it said was "The ordinal 50 could not be located in the dynamic link library jpeg.dll.", and I didn't even try to fix that one. By the time I'd gotten that far, it had already made me add msvcp90.dll, msvcr90.dll, msjava.dll (why the hell?), jvm.dll, verify.dll... Crazy, I tell you! I'm thinking that we can all have a blind "Try this!" and "Well, I would..." session, but quicker would be if there's a way you guys can actually see my settings or something. Is there?

Share this post


Link to post
Share on other sites
Advertisement
Did you use "Release" build instead of "Debug" build? Do all the people you gave your game to have the framework you developed your game on (ex. .Net 3.5) ?

I think there is a program than can look up dependances for exe files but its name escapes me, perhaps someone else can shed some light.

Also, if your exe asks for so many DLLs that you don't even know about, this means there is something not right with either your build set up, or with the end-user's computer.

The msvcp90.dll sounds like a Visual Studio 2008 dll - you shouldn't need that in your final build... but it might be included in the debug (check your output window during debug build and you'll see it loads up a whole bunch of useless dlls). So again, make sure you're not giving them your debug build.

Share this post


Link to post
Share on other sites
I can verify it is in release mode. Partially because when I try to test the game outside VS, I go to the release folder.

I do have the program that looks up the dependencies. It said that only the Visual Studio dlls were missing. And it said some that the exe didn't even care about were missing, but it ran without them. The thing is, though, if I put ANY dlls in the file, it expects me to supply ALL the dlls. So that's pretty much my basis for whether it will run on someone else's computer. Or at least if it'll run on mine, there's a chance. If it won't, there's none.

"Do all the people you gave your game to have the framework you developed your game on (ex. .Net 3.5) ?"

I don't want them to have to.

"The msvcp90.dll sounds like a Visual Studio 2008 dll - you shouldn't need that in your final build... but it might be included in the debug"

Nope. I had to add it upon request by the program. But seeing as it does sound like a VS dll, I don't think I SHOULD need it, but apparently do?

Share this post


Link to post
Share on other sites
Welcome to one of the only true pains in the butt about visual studio 2005 and on.

Really short answer, copy the directory "Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT" to your programs working directory. Distribute your program with this folder and all of it's contents, and run program normally. [use Microsoft.vc80.net for usage of .net stuff, or the different versions, if you used some strange libraries and settings such as use of openMP. If you did not use anything outside of just straight c++, just the .crt version]. Run your program with this entire folder in your program's working directory. Note that this isn't a 'good' solution, but it works in many cases.

Sorta short answer, [and better answer], try downloading This, and running it on the target machine. It should clear up your problem.

Long answer can be found here [which will lead you likely to the same or a similar conclusion, but will educate you more about what is the problem and why it's there, and will give you an assortment of options with which to combat this stupid problem]

Let us know if it works. Btw, the keyword you're looking for is 'deployment', for future searches and questions [which will fetch you more relevant information from such sources as msdn and google].

[Edited by - Drigovas on January 2, 2008 5:25:41 AM]

Share this post


Link to post
Share on other sites
For the VS C/C++ runtime DLLs, another option is to change your project settings so the runtime is statically linked into your exe.

Go to Project Properties->C/C++->Code Generation and, with Release selected top right, change the runtime library option from /MTd to /MT.

Downsides are that your exe will be bigger, and once distributed, will not benefit from any updates to the runtime that MS may release (although to be fair, if you are distributing copies of these DLLs instead of getting the user to install the runtime package, this will be the case anyway).

Obviously this will not affect any other dependancies your project has.

Share this post


Link to post
Share on other sites
Quote:
Original post by Splinter of Chaos
"Do all the people you gave your game to have the framework you developed your game on (ex. .Net 3.5) ?"

I don't want them to have to.


Specifically (for the .NET Framework), you don't have a choice in this regard. Anything you develop on top of the framework, will only run on top of the framework. I'm talking "in the event" of, which might not apply in your case (and I'm guessing it doesn't).

Share this post


Link to post
Share on other sites
msvcp90.dll is a release DLL (the standard C++ library DLL in fact), the debug version is called msvcp90d.dll.
More details here: http://msdn2.microsoft.com/en-us/library/abx4dbyh.aspx

Share this post


Link to post
Share on other sites
Instead of including msvcr90.dll, msvcp90.dll and msvcm90.dll with your game, simply let your users run the official Visual C++ Runtime 2008 Redistributable. This will properly install the runtime DLLs into the WinSxS folder and should get any standard Visual C++ application running.

Just for clarity, the purpose of those DLLs is:
msvcr90.dll - Good ol' C runtime for Visual C++ 2008 programs. Contains the DLL versions of printf(), fopen(), malloc() etc.
msvcp90.dll - C++ runtime for Visual C++ 2008 programs. Mostly consists of the iostreams library and possible some codecvt tables.
msvcm90.dll - C++ runtime compiled as C++/CLI for .NET interoperability.

Any other dependencies are dependencies you introduced yourself (eg. by using libjpeg, opengl, directx or whatever). I know this doesn't help you at this point in time, but it's a good idea to keep track of these dependencies as you add them and never add even one of them to your system32 directory or anything. That way, if it runs on your PC, you know everything (minus the Visual C++ runtime) is there.

-Markus-

Share this post


Link to post
Share on other sites
Quote:
Original post by EasilyConfused
Go to Project Properties->C/C++->Code Generation and, with Release selected top right, change the runtime library option from /MTd to /MT.


This caused the fallowing error:
Quote:
1>------ Build started: Project: Oribits, Configuration: Release Win32 ------
1>Linking...
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _isspace already defined in LIBCMT.lib(_ctype.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: ___iob_func already defined in LIBCMT.lib(_file.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _fclose already defined in LIBCMT.lib(fclose.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _exit already defined in LIBCMT.lib(crt0dat.obj)
1>LIBCMT.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>C:\Documents and Settings\Owner\Desktop\Programming\C++\WorkSpace\Orbits\Oribits\Release\Oribits.exe : fatal error LNK1169: one or more multiply defined symbols found
1>Build log was saved at "file://c:\Documents and Settings\Owner\Desktop\Programming\C++\WorkSpace\Orbits\Oribits\Release\BuildLog.htm"
1>Oribits - 7 error(s), 1 warning(s)


Thanks for all the replies. I'm going through the Microsoft documentation right now. But something strikes me as odd. I've never had to download a MSVCP-crap thing whenever I've downloaded someone else's work. And distribution shouldn't be hard. VS should be able to simulate how my program will run on other computers and configure it so it'll run without hassle. I'd consider that a F**KING CORE FEATURE! The only reason I even use VS is because, as a last resort, I tried to set SDL up with it and unlike ALL OTHER IDEs, it worked! Hooking myself up with others should be just as easy has hooking others up with me. WHY THE F**K ISN'T IT?

Share this post


Link to post
Share on other sites
I've had your latest batch of errors after doing the same thing that you did (expect on VC++ 2005). I 'fixed' them by explicitly ignoring LIBCMT.lib. I think there were a couple more libraries that I had to ignore after LIBCMT, too. Ignoring them is in the linker settings, underneath where you link to a library.

Hardly a fix, and I have no clue why this happens. I was also using SDL, which might, I think, be a problem. Try recompiling SDL from source using the same settings as you're using for your project, if you have time or my above doesn't work.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!