Sorry, I do not know what host triplet, target triplet, or build triplet mean. 
None of them are discussed in http://gcc.gnu.org/bugs.html.  

Here is the output of gcc -v:

cmh204@sea-lion:~/sandbox/newchords$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-2)

The gcc commands I am using are:
cmh204@sea-lion:~/sandbox/newchords$ g++ -g ChordData.cpp Progression.cpp
ChordSearchTree.cpp CAHServer.cpp -o CAHServer
and
cmh204@sea-lion:~/sandbox/newchords$ g++ -g ChordData.cpp Progression.cpp
ChordSearchTree.cpp CAHClient.cpp -o CAHClient

The bug involves two members of class CCHChordSearchTree, which you can find in
ChordSearchTree.ii.  The two members are "CCHProgression m_nBest[ 10 ];" and
"list<CCHProgression *> m_lQueue;"  If the members are listed in that order,
everything works perfectly.  If their order is reversed, compilation and linking
succeeds, but there is an error at runtime.  Specifically, the call to
recvfrom() in CCHChordSearchTree::ClientLoop() fails with an error "Invalid
argument".  At the time of the call, I know that each of the arguments is in
fact valid.

Perhaps this should be a bug report to the writers of the Standard Template
Library or the socket interface, but because it is affected by the order of
member variables it seems to be a compiler problem.



By the way, everything works on another system I have tried, where gcc -v
provides this:

io:~/sandbox/newchords2% gcc -v
Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)