After graduating from school with a bachelor’s degree of computer science, I must admit that I knew virtually nothing about developing *NIX based applications (that’s UNIX / Linux based applications for the non-geeks out there). Granted, I did do a little bit of non-Windows based programming while in school, but it was always incredibly basic stuff: compiling one or two source files, or occasionally writing a make-file for larger projects (three or four source files). Having never had a Linux or UNIX box to play with outside of school, I just never got a chance to get my feet wet. Thankfully, my job at IBM has changed that.
Over the past few weeks, I’ve been doing a great deal of Linux programming, thanks to the cross-“platformedness” of one of the projects I’m working on. And this project is way more complicated than your typical school assignment. I’m now horsing around dynamically linked libraries, also known as “shared objects” in Linux land, like nobody’s business. Not only that, the project itself is essentially a multi-threaded shared object, making it all the more exciting. I’ve learned more about g++, ld, and ldd in the past few weeks than I ever knew before.
Unfortunately, debugging multi-threaded shared objects is easier said than done. The debugging tools in Linux (at least the ones I’ve played with) all suck so horribly. They make you really appreciate the level of quality in Microsoft’s Visual Studio debugger, or better yet, in WinDBG (this thing is hard core, and it’s what the MS developers actually use in practice). Fortunately,
printf() always saves the day.
One cool trick I recently employed to debug a library loading problem I was having, is the LD_DEBUG environment variable. If you set LD_DEBUG to a value of versions, the Linux dynamic linker will print all of the version dependencies for each library used for a given command. If you have a Linux box, try it out. Set the LD_DEBUG environment variable, then do an ls. You’ll be amazed at the number of libraries that such a simple command involves.
Although Linux development can be frustrating at times, I’ve already learned a great deal and consider my experiences a great success. If I come across any more useful tips (like LD_DEBUG above), I’ll try my best to post them here (as much for my sake as for yours). Until then, you’ll find me knee-deep in my Linux code. I’ve got a few more bugs to squash.