openssh static build - mission impossible?

[Mr Dash Four]

> Recompiling the same glibc version, but from upstream[1] instead of
> Fedora should theoretically work. Although I agree replacing glibc is
> not without risks.
> You could try to install a libc at a separate path, there is surely a
> way to do that, yet still cross-compile right.
>   
OK, I am currently coming round two alternatives and they are not ideal 
(at least I am in the dark with a few issues which need to be dealt with).

As Howard Chu suggested earlier, I am considering uClibc, mainly for the 
small footprint as well as the possibility to later statically link 
other tools. As it turns out, there is uClibc package on Fedora, so I 
just need to compile this. By the looks of it, it installs in 
/usr/lib/uClibc by default.

Another alternative is, as you suggested above, to compile a "different" 
glibc library using the gcc source from the link you provided earlier 
and install it in a different directory (say /usr/lib/glibc_mod).

The question for me now is this - is there a way to force the *existing* 
gcc to use these new libraries, without reverting to its own version of 
them (/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libc*)? 
If so, how do I do it - via -L/usr/lib/UClibc or -L/usr/lib/glibc_mod or 
by doing something else?

Personally, if I could force the existing gcc to use uClibc and use this 
library to compile openssh and produce a static binary I will be 
well-happy, though I still don't know whether I would need to use the 
crypto library, which was "integrated" into the "old" libc previously?

> Finally, the tone of several of your messages to this ml have been more
> rude than needed. Please try to keep civility.
>   
I am usually courteous to others, but if the same isn't forthcoming (as 
was the case with Peter and Alon) I make sure I swiftly return the 
favour - having to deal with Internet warriors is not what I registered 
on this ML for.