basile wrote:
> Yesterday I tried compiling gcc-4.3.2-r3 on a stock gentoo hardened
> uclibc system (uclibc-0.9.28.3-r7) and hit all the bugs I remembered
> hitting when I was helping Magnus with testing gcc-4* on uclibc. (Like
> the fenv.h issue).
>
> The best success I've had is using the toolchain from the hardened-dev
> overlay.  This includes upgrading both gcc and uclibc: gcc-4.4.1-r2,
> uclibc-0.9.30.1-r1, binutils-2.18-r3.  I can emerge -e world with only
> two issue, sandbox and python.  Take a look at bug 275094 for some clues
> on how to deal with python.  I haven't really tackled sandbox yet.
>   

Yeah, Natanael Copa wrote to me:
> I have a hardened 4.4.1 working for x86 using the gentoo espf patches. I
> needed 3 more patches:
>
> 1. work around the TLS issue (patch from PSM i think)
> 2. work around the always-link-to-libgcc problem.
> 3. hack to fool tell configure script that we dont have
> _Unwind_getIPInfo

I'm not actually sure which patches he is referencing, but it's at least 
one other confirmation that 4.4.1 is the best way ahead.

Given we need to bump from 3.4.6, is it perhaps sensible to give a push 
towards 4.4.1 instead?  The logic being whether it actually breaks less 
stuff on average than going to 4.3?

Cheers

Ed W