Sure, the problem was installing gfortran, which (as I recall) requires the real gcc. I suspect (though I never did figure out what exactly was wrong) that some sort of a library conflict with xcode's gcc was responsible. As this package is still not the real gcc (they don't want gpl v3 I believe) anyone who wants eg. gfortran will still need a separate installation.
gcc and glibc are different things, and gcc does not require glibc. I don't know that glibc even runs on OS X/Darwin, it would seem strange for any time to be invested in such an endeavour.
I can't find any evidence of that. The gfortran 4.3 release notes strongly imply it doesn't:
"Support for backtraces on glibc-based systems via the -fbacktrace option is now implemented. On all systems, a coredump can be generated for errors in the run-time library using `-fdump-core`."
The GCC suite has a pretty clear history of not being dependent on glibc, and some searching brings up no mention of it requiring glibc, and a few mentions of people clearly building it without glibc.
'I have been attempting unsuccessfully to try the latest gfortran snapshot executables...The reason for the problem is that they require the bleeding-edge
version of GLIBC to run:'
key excerpt being: 'One problem is that the functions csqrt, csqrtf, csqrtl of libm (glibc) which are used by gcc4 are still buggy for x86_64 architectures...'
Your first link is about gfortran executables for Linux (specifically a specific snapshot build, not the source code itself), not OS X. Your second one is about glibc systems, not OS X, is over six years old, and complains simply about buggy functions in glibc -- what is it that makes you think using glibc would solve a glibc problem?
Neither of these in any way imply a general dependency on glibc. On the contrary, the second one implies you'd have more luck without it, if the issue were still extant -- which it's not, the bugs were closed out six years ago.