Fun With Linux Development

Published on July 20, 2006

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.

2 Comments

kip

I have to admit I don’t know much about Linux either. I never got around to turning an old machine into a Linux box like a lot of other people did. I work on C++ and Java that has to compile on Windows 32-bit, Windows 64-bit, AIX 32-bit, AIX 64-bit, Solaris, HP-UX, and IRIX (SGI’s Unix). Which may sound like a lot, but people before me have pretty much done all the hard work for me.

We have a build tool, called “mkmk”, which makes a makefile then uses that to make the binaries. So it’s not really all that much different from when I was coding for one platform except for a few annoying issues (like HP and IRIX compilers don’t have a “bool” or “boolean” type, so you have to remember to use BOOL which is just #defined as short int).

Anyway I was going to say that AIX has a usable (but very buggy) C++/Java debugger called idebug, and solaris has a nice one (with a good set of profiling tools) called workshop. If you ever need to debug on one of those platforms be sure to look into those.

enc

I used to use gdb debugger under Linux while learning about kernel & sys-calls co.

I don’t know if it’s good to debug shared objects’n’stuff, bet it suited my requirements.

Comments are closed.

Copyright © 2004-2019 Jonah Bishop. Hosted by DreamHost.