* If configure fails with a 'cannot run C compiled programs' error, try this: * FEATURES=-sandbox emerge sandbox By utilising the new EBUILD_DEATH_HOOKS feature in portage-2.0.53 this message could be delivered to the user after the actual failure so it would be easier for the user to correct the problem.
considering 2.0.53 hasnt been released yet let alone be in stable, it's not like it'd be of much use
(In reply to comment #1) > considering 2.0.53 hasnt been released yet let alone be in stable, > it's not like it'd be of much use Well it is of course in the rc releases and it is expected it to hit stable during this week. You can of course do something like the following: if ! hasq java-pkg_die $EBUILD_DEATH_HOOKS; then EBUILD_DEATH_HOOKS="$EBUILD_DEATH_HOOKS java-pkg_die" fi
>* If configure fails with a 'cannot run C compiled programs' error, try this: > * FEATURES=-sandbox emerge sandbox Err... maybe I'm missing something, but I don't recall ever seeing sandbox having a hand in this specific failure. Screwed toolchain, screwed C.*FLAGS, yes, sandbox? The hooks *really* should never be used to tell users to disable QA measures without knowing the QA measures are at fault.
you are missing something search bugzilla history for past sandbox bugs you cant run 32bit code without a 32bit sandbox
(In reply to comment #3) > > The hooks *really* should never be used to tell users to disable QA measures > without knowing the QA measures are at fault. If you read my bug report you will see that this is not about the QA message itself at all. It is about the way it is reported to the user. What you are saying means that the message should not be there at all and is an another bug report, but of course the fix for it would fix this too.
added to cvs, thanks for the suggestion http://sources.gentoo.org/sys-apps/sandbox/sandbox-1.2.20_alpha2-r1.ebuild?r1=1.3&r2=1.4
