Summary: | sys-libs/uclibc-2.9.30 fails to compile under hardened sys-devel/gcc-3.4.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ed Wildgoose <gentoo> |
Component: | New packages | Assignee: | Embedded Gentoo Team <embedded> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | bertrand |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 229623 | ||
Attachments: | patch for gcc 3.4.6 building uclibc |
Description
Ed Wildgoose
2009-06-26 17:37:58 UTC
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 |