Jason Copenhaver

My wife and I recently went on a nature trip.  Three days hiking and sleeping in the woods, followed by two days at a campground nearBrooksville .  I turned my cell phone off on Friday and didn’t turn it back on until Tuesday.  Loved it.  Just some thoughts I had along the way

1.  It’s actually really easy to go 5 days without twitter, facebook, RSS feeds, digg, etc.  All told nothing that important happened while I was gone, and it’d probably be the same for any week out of the year.
2.  Natural bug repellent doesn’t work, or I’m just too damn delicious.
3.  Nothing is more peaceful than canoeing down a river, even one that is only 6 inches deep.
4.  State parks don’t allow alcohol.
5.  The dog drinks just as much water as we do but he’s too small to carry his own.

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.