Removing the need for additional dependencies

Started by
6 comments, last by Stephen R 15 years, 9 months ago
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.
Advertisement
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.
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?
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.
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__fprintf1>SDLmain.lib(SDL_win32_main.obj) : error LNK2001: unresolved external symbol __imp__strrchr1>C:\Documents and Settings\Steve\My Documents\C++\SDL\Release\Bray-Kowt.exe : fatal error LNK1120: 2 unresolved externals
This post seems to suggest NOT excluding msvcrt.lib to fix that error. Worth a try. Unfortunately I can't test this. I'm running linux in work.
Thanks for your help, but yeah, not excluding msvcrt.lib added to the error count. Gah.
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.

This topic is closed to new replies.

Advertisement