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
