| 1 |
basile wrote: |
| 2 |
> Yesterday I tried compiling gcc-4.3.2-r3 on a stock gentoo hardened |
| 3 |
> uclibc system (uclibc-0.9.28.3-r7) and hit all the bugs I remembered |
| 4 |
> hitting when I was helping Magnus with testing gcc-4* on uclibc. (Like |
| 5 |
> the fenv.h issue). |
| 6 |
> |
| 7 |
> The best success I've had is using the toolchain from the hardened-dev |
| 8 |
> overlay. This includes upgrading both gcc and uclibc: gcc-4.4.1-r2, |
| 9 |
> uclibc-0.9.30.1-r1, binutils-2.18-r3. I can emerge -e world with only |
| 10 |
> two issue, sandbox and python. Take a look at bug 275094 for some clues |
| 11 |
> on how to deal with python. I haven't really tackled sandbox yet. |
| 12 |
> |
| 13 |
|
| 14 |
Yeah, Natanael Copa wrote to me: |
| 15 |
> I have a hardened 4.4.1 working for x86 using the gentoo espf patches. I |
| 16 |
> needed 3 more patches: |
| 17 |
> |
| 18 |
> 1. work around the TLS issue (patch from PSM i think) |
| 19 |
> 2. work around the always-link-to-libgcc problem. |
| 20 |
> 3. hack to fool tell configure script that we dont have |
| 21 |
> _Unwind_getIPInfo |
| 22 |
|
| 23 |
I'm not actually sure which patches he is referencing, but it's at least |
| 24 |
one other confirmation that 4.4.1 is the best way ahead. |
| 25 |
|
| 26 |
Given we need to bump from 3.4.6, is it perhaps sensible to give a push |
| 27 |
towards 4.4.1 instead? The logic being whether it actually breaks less |
| 28 |
stuff on average than going to 4.3? |
| 29 |
|
| 30 |
Cheers |
| 31 |
|
| 32 |
Ed W |
Archives