Summary: | app-editors/emacs-22.1-r3 fails on s390x due to multilib assumption | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | s390 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://news.gmane.org/find-root.php?group=gmane.emacs.bugs&article=17345 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emacs-22.1-s390x-non-multilib.patch
emacs-22.1-r3.ebuild.diff emacs-22.1-s390x-non-multilib.patch (take 2) |
Description
SpanKY
2008-01-13 01:10:04 UTC
Created attachment 140843 [details, diff]
emacs-22.1-s390x-non-multilib.patch
Please try if this patch fixes it.
Created attachment 140845 [details, diff]
emacs-22.1-r3.ebuild.diff
Patch for the ebuild itself, adds --libdir option to econf.
econf already sets up --libdir so you dont need to do it ... unless you're doing it to work around having to export more vars to the Makefile ? imo, you would want to add to the Makefile.in: prefix=@prefix@ exec_prefix=@exec_prefix@ libdir=@libdir@ and then the vars fall into place the call is yours, either method should work fine (ive tested the latter of placing all vars into Makefile.in) Created attachment 140851 [details, diff] emacs-22.1-s390x-non-multilib.patch (take 2) (In reply to comment #3) > econf already sets up --libdir so you dont need to do it ... > imo, you would want to add to the Makefile.in: > prefix=@prefix@ > exec_prefix=@exec_prefix@ > libdir=@libdir@ > and then the vars fall into place Right, there is no need for multilib.eclass here. Updated patch attached. Fixed in CVS. Could you confirm again that it works? Then we can report it upstream. works great, thanks Ulrich, you report upstream? Gna, reopen for proper resolution (In reply to comment #7) > Ulrich, you report upstream? Yes, as soon as you are through with your status changes of this bug. :p Looks like Upstream is going for a different solution. Previous patch replaced by the one included in <http://thread.gmane.org/gmane.emacs.bugs/17345>. > Previous patch replaced by the one included in > <http://thread.gmane.org/gmane.emacs.bugs/17345>. Argh, this should be <http://article.gmane.org/gmane.emacs.bugs/17354>. |