Most of what you say is true, but, bitcoin tends to be built against very specific versions of its dependent libs. Due to that, one tends to build bitcoin against custom compiled libs, regardless of underlying OS version. That practice makes glibc the primary compatibility worry.
Please cite exactly which library is using which feature of very recent glibc version (or any library for that matter) ? (just so we can all understand the problem in the way you state).
From what I can see wxWidgets and boost are linked statically. I guess this is due to the "build against very specific versions of its dependent libs". But from what I can see there is _NO_ need for either of thes libraries to use a recent glibc, wxWidgets for example only has a check for glibc 2.1 or newer (during its ./configure). But it is not clear which features of wxWidgets 2.9.0 and/or boost 1.40.0 require the use of a glibc say above version 2.5 (which is also pretty old, but pretty compatibile). I have sucessfully been able to build these versions (of wxWidgets/boost) against glibc 2.5.
I believe this can be confirmed by the use of -Bstatic in "src/makefile.unix".
The only reason that glibc is a "compatibility worry" (as you put it) is because the project was build on a very new linux system. This forces all the downloaders to have as-new-a linux system as the build system in order to run it. This is not because there is some intrinsic compatibility worry as you describe it.
I think I have created a custom wxWidgets 2.9.x build on OpenSUSE build service (OBS). I shall have a go with "boost" over the new few hours if all goes well. Then I can commit bitcoind package and get openSuSE builds. Then I can enable other distribution repos (CentOS, Ubuntu, SLE, Fedora, etc...).
Can anyone confirm if boost "1.40.0" is needed or just "1.40.0 or newer" ? since 1.42.x is current (and that is already available for a number of platforms as packages). Can anyone explain the story behind this matter.
With wxWidgets 2.9.x is a development series so it is pre-release, so that is clear cut that a custom version needs to be built to get access to pre-release versions. But this problem I have solved in an OBS build.