Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 205555 - app-editors/emacs-22.1-r3 fails on s390x due to multilib assumption
Summary: app-editors/emacs-22.1-r3 fails on s390x due to multilib assumption
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Emacs project
URL: http://news.gmane.org/find-root.php?g...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-13 01:10 UTC by SpanKY
Modified: 2008-01-17 13:11 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emacs-22.1-s390x-non-multilib.patch (emacs-22.1-s390x-non-multilib.patch,891 bytes, patch)
2008-01-13 03:04 UTC, Ulrich Müller
Details | Diff
emacs-22.1-r3.ebuild.diff (emacs-22.1-r3.ebuild.diff,645 bytes, patch)
2008-01-13 03:06 UTC, Ulrich Müller
Details | Diff
emacs-22.1-s390x-non-multilib.patch (take 2) (emacs-22.1-s390x-non-multilib.patch,969 bytes, patch)
2008-01-13 09:30 UTC, Ulrich Müller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2008-01-13 01:10:04 UTC
the emacs build system makes assumption about multilib setups based on the target architecture

src/m/amdx86-64.h:#define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o
src/m/amdx86-64.h:#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o
src/m/ibms390x.h:#define START_FILES pre-crt0.o /usr/lib64/crt1.o /usr/lib64/crti.o
src/m/ibms390x.h:#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib64/crtn.o

this probably isnt a big deal for amd64, but on s390x, /usr/lib64/ does not exist in a non-multilib setup.  there is only /usr/lib/.
Comment 1 Ulrich Müller gentoo-dev 2008-01-13 03:04:49 UTC
Created attachment 140843 [details, diff]
emacs-22.1-s390x-non-multilib.patch

Please try if this patch fixes it.
Comment 2 Ulrich Müller gentoo-dev 2008-01-13 03:06:10 UTC
Created attachment 140845 [details, diff]
emacs-22.1-r3.ebuild.diff

Patch for the ebuild itself, adds --libdir option to econf.
Comment 3 SpanKY gentoo-dev 2008-01-13 05:39:25 UTC
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)
Comment 4 Ulrich Müller gentoo-dev 2008-01-13 09:30:32 UTC
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.
Comment 5 Ulrich Müller gentoo-dev 2008-01-13 09:51:05 UTC
Fixed in CVS. Could you confirm again that it works? Then we can report it upstream.
Comment 6 SpanKY gentoo-dev 2008-01-15 10:05:34 UTC
works great, thanks
Comment 7 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-15 10:10:59 UTC
Ulrich, you report upstream?
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-15 10:14:35 UTC
Gna, reopen for proper resolution
Comment 9 Ulrich Müller gentoo-dev 2008-01-15 14:10:26 UTC
(In reply to comment #7)
> Ulrich, you report upstream?

Yes, as soon as you are through with your status changes of this bug. :p
Comment 10 Ulrich Müller gentoo-dev 2008-01-17 08:01:55 UTC
Looks like Upstream is going for a different solution.
Comment 11 Ulrich Müller gentoo-dev 2008-01-17 13:07:54 UTC
Previous patch replaced by the one included in <http://thread.gmane.org/gmane.emacs.bugs/17345>.
Comment 12 Ulrich Müller gentoo-dev 2008-01-17 13:11:02 UTC
> 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>.