Sign in to follow this  
BigFreak

Removing the need for additional dependencies

Recommended Posts

I'm trying to create a demo which will not require additional dependencies on target machines, as I assume trying to get the Visual C++ 2008 Runtime files installed will be a nightmare for HR types and such, with regards to having install permissions. I've read several threads regarding this issue, but following the advice given, I just couldn't get the program to compile. I've created an SDL program, and trying to compile as Multi-threaded (/MT) rather than Multi-threaded DLL gives a slew of linker errors:
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\Steve\My Documents\C++\SDL\Release\Bray-Kowt.exe : fatal error LNK1169: one or more multiply defined symbols found

Any help will be greatly appreciated! Cheers.

Share this post


Link to post
Share on other sites
With regard to VC++ 2008 dependancies, it should just be a case of having the correct runtime dll in the same folder as the exe. You shouldn't be required to install that package on a machine to run your app. 'msvcr90.dll' I think is the right one.

Here is the table of dlls and runtimes.

EDIT: This is presuming the only VC related dependancy is the runtime dll, which for most SDL apps is the case.

EDIT2: This link though should help get rid of those errors. Lists what libraries to ignore depending on the RT selected.

Share this post


Link to post
Share on other sites
Yeah, I'm not 100% sure but I think there's issues with the license agreement in doing that. The redist.txt says this:

"For your convenience, we have provided the following folders for use when redistributing VC++ runtime files. Subject to the license terms for the software, you may redistribute the folder (unmodified) in the application local folder as a sub-folder with no change to the folder name. You may also redistribute all the files (*.dll and *.manifest) within a folder, listed below the folder for your convenience, as an entire set. "

...from which I take that if I dump all the files into a zip with my app. that should be fine?

Share this post


Link to post
Share on other sites
Aye, reading up on it (it seems I've been breaking the rules for a LONG time [smile]), it seems you can just include the correct folder in the folder your app is in. You will need to make a manifest file though I believe.

Share this post


Link to post
Share on other sites
Quote:
Original post by Stephen R
EDIT2: This link though should help get rid of those errors. Lists what libraries to ignore depending on the RT selected.

Thanks for that! Greatly reduced my errors, ignoring:
Multithreaded (libcmt.lib) libc.lib, msvcrt.lib, libcd.lib, libcmtd.lib, msvcrtd.lib

but I guess that takes out a library SDL uses for its window management or something, cos it leaves me with this:
1>SDLmain.lib(SDL_win32_main.obj) : error LNK2001: unresolved external symbol __imp__fprintf
1>SDLmain.lib(SDL_win32_main.obj) : error LNK2001: unresolved external symbol __imp__strrchr
1>C:\Documents and Settings\Steve\My Documents\C++\SDL\Release\Bray-Kowt.exe : fatal error LNK1120: 2 unresolved externals

Share this post


Link to post
Share on other sites
I'm not sure if you're going to be able to get away with not using Multithreaded DLL, at least not without recompiling SDL against Multithreaded (no idea how good an idea that is). It's not looking like it's going to work tbh.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this