Skip to main content
gamedev.net
🔒 Locked

Linking Problems

Started by Icebone1000 2 replies 1.6k views
Original Post
Icebone1000
Icebone1000
Hi.. I guess everyone know about the error you noyice when triing to run your program on another computer, something about "side-by-side".. Ok..Googling about it I notice I just have to use MT or MTd configurations(and not MD, MDd) so it will not include the runtime.. Ok, here is where my problem starts, using MTd generates lots and lots of errors..I noticed mostly of these errors disappear by setting msvcrt.lib to the list of ignored libraries.. But Im using SDL, and Im getting this error now: SDLmain.lib(SDL_win32_main.obj) : error LNK2019: unresolved external symbol __imp__fprintf referenced in function _ShowError Notice that no errors(neither warnings) was happening when I was using MDd..but i want use MTd to not get the damn "bla bla side-by-side bla bla error".. Also, im getting some warnings too: SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _isspace imported in function _ParseCommandLine SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol ___iob_func imported in function _ShowError SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _fclose imported in function _cleanup_output SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _exit imported in function _main SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _strrchr imported in function _main How can I avoid it?
hh10k
hh10k
Although MD and MDd requires you to package the Visual C++ runtime with your application, it's a better option than statically linking with MT or MTd. A statically linked runtime in each executable and DLL results in a lot of duplication, and you will have problems when you try to pass things between them, like FILE*s.

To get rid of those warnings, your best bet is to download the source for SDL (and its associated dependencies) and build them yourself with a consistent set of build options (and consistent compiler). MD for the release build, and MDd for the debug build. It's easier if the debug versions of a library have some form of postfix like '_debug' so you know what you're linking against. It may seem like a lot of effort at first, but once you get used to it it will save you many headaches in the future :)

Don't add a library to the ignore list unless you really have to. It's more of a hack for libraries which you don't have the source code for.
Icebone1000
Icebone1000
woah..o_o
"Don't add a library to the ignore list unless you really have to."
But if I dont ignore that msvcrt.lib I get 223 errors, I think this is a "you really have to" situation right?

Your post freaked me out, I will see what I can do( IF I can do... ._.)
BitMaster
BitMaster
These errors happen because all of the other libraries you are linking against are compiled using MD/MDd and they want all standard library function to come from there. The only way to fix it is to compile all of them using MT/MTd which can be simple or insanely difficult depending on the library.

Just setting the mscvrt.lib to be ignored is indeed just a nasty hack. It might work, but sooner or later you WILL run into crashes you cannot explain. Either compile everything with MT/MTd (taking care to link the correct libraries) or stick with MD/MDd.

You can also consider linking dynamically against those libraries but since you didn't like the idea of DLLs in the first place this is probably not what you want. And, depending on the library, it might not help since the libary might rely on everything using the same runtime which will, for example, not be fullfilled if you allocate something in your program and then passing the pointer (including ownership) to the library.

Topic Locked

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

Sign in to reply to this topic.