Hi, I guess uclibc doesn't get much love, but patch attached for this issue so perhaps this might move ahead... It appears that gcc 3.4.6 doesn't properly compile uclibc 2.9.30 and in particular the -fomit-frame-pointer causes problems for anything linked to -lpthread Although this is a fairly old gcc, it's also the current for hardened There is a patch to uclibc here (with discussion) http://lists.uclibc.org/pipermail/uclibc/2008-November/041416.html Patch is attached above Currently testing this with x86 and seems to be working nicely here. Reproducible: Always Steps to Reproduce: To repro, simply emerge uclibc 2.9.30 with gcc 3.4.6 and you will find your system very broken and almost everything segfaults immediately. Recover if you can by untaring your previous package (qmerge wouldn't work for me)
Created attachment 195823 [details, diff] patch for gcc 3.4.6 building uclibc
gcc-4.x is stable on hardened systems now
(In reply to comment #2) > gcc-4.x is stable on hardened systems now > 4.x is not stable on any hardened profile. Only 4.3.4 has support and it actually still misses SSP support.
then i'll tweak the resolution
Closing it as "won't fix" seems a bit harsh? I just posted the patch - why not apply it?? At least a reason for not applying it would be helpful?
because it's wrong and applies to all versions rather than restricting itself to broken ones
In what way is it "wrong"? (How do I learn if I don't ask?) If it simply needs the patch changing to only be applied if "USE=hardened", then perhaps you could just indicate that instead of closing with "won't fix"? It actually appears to do nothing harmful in the non hardened case though? I might be missing the point if it screws with gcc-4, (however, is there any sign that this will actually appear for hardened in the next 10 years?)
i already explained in my last comment how it is wrong
Sorry, can you just spell it out please. Your previous two comments were: then i'll tweak the resolution and 4.x is not stable on any hardened profile. Only 4.3.4 has support and it actually still misses SSP support. Neither of these seem to explain what the problem is. I might be misreading your penultimate post, but it uses an "and", so it implies two things are wrong? "because it's wrong and ..." But in any case I just tried to answer that objection with: "If it simply needs the patch changing to only be applied if "USE=hardened", then perhaps you could just indicate that instead of closing with "won't fix"? It actually appears to do nothing harmful in the non hardened case though? I might be missing the point if it screws with gcc-4, (however, is there any sign that this will actually appear for hardened in the next 10 years?)" So I'm hoping you will actually address my comments above rather than just repeating your previous objection anyway. Should we take this onto email/irc? I'm genuinely trying to get this resolved? Ed
I think what vapier is saying is this check alone is not enough. +ifeq ($(TARGET_ARCH),i386) ... vs carpet bombing all x86 it would be better to narrow it down to the exact cases where it's needed like gcc. We don't like to do conditional patching. And USE=hardened is not really descriptive enough. As upstream even says gcc-4.x is a requirement now I think you will want to narrow the checks to check for gcc-3.x etc..
you seem to be missing comment #6
I even quoted comment 6 in my prev email, so I think I'm wasting my time replying further I think it's worth trying to fix this, but it's obviously something of an uphill battle so it can remain a local patch in my tree for the time being Hardened is pretty niche so I guess google will bring this up for those that need it Thanks for listening
WONTFIX -> no plans for us fixing this issue that doesnt mean you cant submit a fix and we'll integrate it if my #6 is confusing, use solar's #10
Sure - agree and understood