Summary: | app-editors/xemacs-21.4.22-r4: emerge hangs and does not finish | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | XEmacs team <xemacs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | all emerge at the end of the failing process recommended outputs |
Description
Toralf Förster
2015-02-20 15:52:23 UTC
This could be the same problem that is reported in bug 75028. A workaround, use "-nopie" flag in CFLAGS, is suggested there. (In reply to Mats Lidell from comment #1) > This could be the same problem that is reported in bug 75028. A workaround, > use "-nopie" flag in CFLAGS, is suggested there. shouldn't the ebuild then filter out / include this flag ? Or is this issue just special (for hardened environments) ? (In reply to Toralf Förster from comment #2) > (In reply to Mats Lidell from comment #1) > > This could be the same problem that is reported in bug 75028. A workaround, > > use "-nopie" flag in CFLAGS, is suggested there. > > shouldn't the ebuild then filter out / include this flag ? Or is this issue > just special (for hardened environments) ? I'm afraid I know to little about hardened environments and what the -nopie flag means so I need to ask for help and surely I have quite some learning to do here. I'm just refereeing to bug 75028 to sort out if we have a duplicate or not. Do we? I do know that the XEmacs build system is a can of worms so I'm not surprised we are seeing odd behaviour. (In reply to Mats Lidell from comment #3) > (In reply to Toralf Förster from comment #2) > > (In reply to Mats Lidell from comment #1) > > > This could be the same problem that is reported in bug 75028. A workaround, > > > use "-nopie" flag in CFLAGS, is suggested there. > > > > shouldn't the ebuild then filter out / include this flag ? Or is this issue > > just special (for hardened environments) ? > > I'm afraid I know to little about hardened environments and what the -nopie > flag means so I need to ask for help and surely I have quite some learning > to do here. I'm just refereeing to bug 75028 to sort out if we have a > duplicate or not. Do we? I do know that the XEmacs build system is a can of > worms so I'm not surprised we are seeing odd behaviour. well, maybe it is the same issue Created attachment 404710 [details]
all emerge at the end of the failing process recommended outputs
Not hardened environment
(In reply to CaptainBlood from comment #5) > Created attachment 404710 [details] > all emerge at the end of the failing process recommended outputs > > Not hardened environment From the environment info in the attachment follows that EXTRA_ECONF="--disable-dependency-tracking --enable-silent-rules". Unfortunately configure for XEmacs does not support these flags and thus configure fails. If you unset EXTRA_ECONF when building xemacs things should work better. b/c it still happens the ebuild should be tweaked ? I'm sorry but I fail to see your point. Please elaborate. (In reply to Mats Lidell from comment #8) From the previous comment >>If you unset EXTRA_ECONF when building xemacs things should work better. If that is a valid bug fix then it should be incorporated into the ebuild. Sorry for being unclear. The suggestion is not a bug fix because this is not a bug. Letting the ebuild modify EXTRA_ECONF would be against the purpose of the variable. If I understand correctly the variable EXTRA_ECONF is a tool for a user who wants to tweak an ebuild without modifying it. But the options set this way must of course be supported by the package in questions for it to work properly. In this case the user used options that configure for XEmacs does not support and thus configure fails. hhm, putting this in package.use helps : app-editors/xemacs -nopie IMO an ewarn should be included in the ebuild to reflect this. (In reply to Toralf Förster from comment #11) forget that comment. This reported problem is very likely a duplicate of https://bugs.gentoo.org/639214 which is now solved for xemacs-21.4.24.ebuild. So I consider this as fixed. |