I have a multithreaded Perl ICB client, ICBM. It works perfectly on my primary workstation, which runs what can only be described as a custom distribution based long ago on Slackware 7. I also have a Gentoo "sandbox" machine which differs from it in, naturally, a large number of ways. I've been using the sandbox to develop a Gentoo install that I can use to completely refresh the OS on my workstation.
ICBM did not work on the sandbox. Well, that is, it all worked ... until you quit. Then it'd hang on exit. Forever.
Tonight, I spent a couple of hours debugging this problem and finally tracked it down to a single line of code in the function that handles commands sent to ICBM through its local control FIFO, in the thread that handles input from other processes:
open(FIFO, $icbmfifo);
I finally discovered that what was happening was that open() call was never returning until something wrote to the other end of the FIFO. Turns out my dev workstation is running Perl 5.10.0, compiled from source ... while the Gentoo sandbox is still running 5.8.8, old as that now is. (5.8.8.was released on January 31, 2006. 5.10.0 was released Dec 18, 2007. So even 5.10.0 is over a year old.)
Why this is significant is because in my Perl 5.10.0, open() implies O_NONBLOCK. But in Gentoo's Perl-5.8.8 ebuild, it does not.
Now, I was able to work around the problem, doubtless at some cost in portability, by using sysopen() instead:
sysopen(FIFO, $icbmfifo, O_RDONLY|O_NONBLOCK);
But this is a good example of how previously perfectly working things can break when someone changes a subtle, undocumented detail of how something underlying your code works.
Next (and, I think, probably last) problem to solve: Finding out (and hopefully fixing) why XCoral SEGVs on launch on the Gentoo box.
Update:
That proved amusingly simple: There's a newer version since I last downloaded it. v3.4.6 works on babylon5 but SEGVs on sandbox; v3.4.7 works fine on sandbox ... and, yeah, you guessed it, SEGVs on babylon5.