I don't usually pay too much attention to the link order when I'm adding libraries to my application. Something says you need "foo.lib", open up the project properties and drop in "foo.lib". This failed for me recently. I was trying to statically link two internal libraries that share a significant code base. At first I was confronted with a dozen errors about colliding symbols. This didn't bother too me too much at first. Colliding symbols are pretty easy to take care of, just rename one set of them, these are both straight C libraries so nothing fancy. After making my changes I made a sample project that just linked to both of the libraries to make sure I had resolved everything. To my surprise I now had a dozen NEW colliding symbols. After careful inspection I noticed that the link order was different and this was indeed hiding colliding symbols. This is when I thought back to that option "Enable Function Level Linking" A very handy function that allows the linker to take only the functions it needs from a library when building the final application. However, if you have two libraries with the same symbols and one of them has function-level linking enabled it can hide these kind of errors. The linker will happily take a function from foo.lib and then when it sees the same function in bar.lib, that has function-level linking enabled, it'll simple ignore it because it doesn't need it. Worse if you really wanted the function from bar.lib, you now have the function from foo.lib so there is a very good change something will break in a mysterious way. From now on I'm going to try and keep my function-level linking libraries in the front of the link list, and try keep my legacy code from colliding with my other legacy code.