Saturday, September 27, 2008

Cross-Compiling, gotta love it

I just spent the past couple of hours figuring out why I wasn't able to compile the Player server with plugin capabilities. It turns out that there were many intermediate steps that were axing the ability.

First obstacle: configure.ac
The autoconfigure script for the player project had a macro called AC_CHECK_LIB that checked to see if I had libltdl installed. Now, I have both libltdl for my system(system A) as well as libltdl for the target system(system B). If I want to cross-compile, then there's no way for this check to work because it tests for the existence of libraries by compiling, linking, and running a piece of test code with a particular function within the library. Since I'm compiling using B's libltdl, yet the check wants to run on architecture A, we have a problem!! To circumvent this, I simply removed the check and told the configure script to simply compile with the appropriate flags. (LIBS = -lltdl -dl $LIBS)

Second obstacle: misconfigured paths
After fixing the makefiles and ensuring the appropriate compile time flags were set, I went ahead and tried making the program only to find, Oh Noes! the program wasn't looking for libltdl in the right location. It was apparently looking for it in the standard /usr/lib/ directory. I figured this would be an easy fix as all I would have to do would be to change some path. As it turns out, I tried changing LD_LIBRARY_PATH, which on my distro of linux prepends that string to the path that ld searches. This didn't work either, and it kept insisting that libltdl was /usr/lib/libltdl.so. I was a little fed up at this point and didn't feel like reading about the intricacies of how ld caches library locations and deals with alternate scenarios like mine, so I simply made a soft link in /usr/lib to the real library that I wanted to link with.


Presto!! Out comes the beautiful binaries that I've been looking for this whole time!

Now I can finally get to testing the drivers I wrote for Player so that I can start reading range finder information over the network. Score!!!!

Wednesday, September 24, 2008

Robot Progress

Recently, I've been working on setting up a robot for the introductory CS class here at Rice. Because our interface to the robot is wireless through a small GNU/Linux computer, I've been able to learn oodles about how to do networking, cross-compiling, building kernel modules, etc for and embedded system. I would have never learned this from just taking a class. Sometimes I really think this whole higher education system is overrated.

Regardless, it's really been a great experience!

Some handy topics I learned more about today: automake, autoconf, readelf, objdump, CPLUS_INCLUDE_PATH, pkg-config, PKG_CONFIG_PATH, etc...

Developer tools rock!

Wednesday, September 17, 2008

Software Project Management

Just recently, I've started a course on software development. What?!? You might be thinking, how can a University level course teach something that can't be found in a book? The answer to that question is, we're not using books! The approach this class is instead to force a bunch of awkward, stinky CS majors together in a room and lock us up until we churn out a enterprise level piece of software.

Now I know that hardly sounds any better than reading from a book, and I'm sure it has the makings for a sci-fi horror movie, but it's actually not as bad as it seems. There are 6 of us who are truly dedicated to learning to work together, self-organize, design, document, code, and debug a large piece of software. I think we have great potential!

So far, the class and the meetings have been more like a comedy. We've done everything from pulling hysterical all-nighters, singing the cake song from Portal into the night, to coding to intense Trance music with awesome visualizations up on the big screens of the computer lab where we temporarily reside this semester.

Alright, now for the meat of the post, this is what I've actually learned in this short time...
  1. Incremental Iterative approach
  2. Avoiding waterfall design
  3. Use Cases
  4. Domain Modeling
  5. System Sequence Diagrams
  6. Operational Contracts
These themes have helped us so far guide our search for specific project requirements, and hopefully they will help us cut our time in half when it comes to actually trying to code our system. If you are looking into learning about project development, look some of these terms up, it will be very worth your while!

- Nick