{ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the other with egcs (any version). Egcs has functions in its internal `libgcc.a' to support exception handling with C++. They are linked into any program or dynamic library compiled with egcs, whether it needs them or not. Dynamic libraries then turn around and export those functions again unless special steps are taken to prevent them.
When you link your program, it resolves its references to the exception functions to the ones exported accidentally by libc.so. That works fine as long as libc has those functions. On the other system, libc doesn't have those functions because it was compiled by gcc 2.8, and you get undefined symbol errors. The symbols in question are named things like `__register_frame_info'.
For glibc 2.0, the workaround is to not compile libc with egcs. We've also incorporated a patch which should prevent the EH functions sneaking into libc. It doesn't matter what compiler you use to compile your program.
For glibc 2.1, we've chosen to do it the other way around: libc.so explicitly provides the EH functions. This is to prevent other shared libraries from doing it.
{UD} Starting with glibc 2.1.1 you can compile glibc with gcc 2.8.1 or newer since we have explicitly add references to the functions causing the problem. But you nevertheless should use EGCS for other reasons (see question 1.2).