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/.
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>.
