Description of problem: emacs-25.0.95 build fails on ppc64 architecture for both BE and LE with following message: "Memory exhausted--use M-x save-some-buffers then exit and restart Emacs" Detailed build log is available at koji build http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3537924 Version-Release number of selected component (if applicable): emacs-25.0.95-1 Additional information: Tried building locally on ppc64 BE box and found that emacs needed around 15GB of memory to build successfully which is pretty high than expected.
Created attachment 1180084 [details] emacs patch for powerpc I am providing a workaround patch which fixes memory issue during build process. This patch runs "make bootstrap" under "setarch -R". Successful koji scratch build link after applying this patch - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3538290 More detailed discussion around this problem is going on at libc-alpha ML https://sourceware.org/ml/libc-alpha/2016-07/msg00430.html. Will update here if I have any better solution.
Update ------ Emacs builds and works fine on ppc64(le) with patch proposed at https://sourceware.org/ml/libc-alpha/2016-07/msg00481.html Koji scratch build with patch applied is available at http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3538651
This was fixed in http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e95b023163e96538b15f030b7176b7ec59cf86f5.
(In reply to Jan Synacek from comment #3) > This was fixed in > http://git.savannah.gnu.org/cgit/emacs.git/commit/ > ?id=e95b023163e96538b15f030b7176b7ec59cf86f5. Based on <https://sourceware.org/ml/libc-alpha/2016-07/msg00505.html>, Emacs still does not build with this patch. This is not too surprising because the real fix has to be in src/gmalloc.c because it can't deal with huge gaps between .data and the the heap.
Ok, I must have missed the follow up. I won't apply the patch yet.
Can we get eg. the "setarch"-based workaround in place until there is a proper solution on emacs side? Because the lack of emacs 25.0.95 build blocks the automated builds for Rawhide on ppc64/ppc64le.
Created attachment 1181243 [details] emacs build fix for ppc64(le) arch So far, I think patch proposed at https://sourceware.org/ml/libc-alpha/2016-07/msg00481.html works well for ppc64(le) in Fedora rawhide. Based on it I have prepared a setarch patch which is available in bugzilla attachment. Patch gets applied only for ppc64(le) and Fedora release > 24. With this patch emacs builds fine for all architectures for Fedora, rawhide. Some successful scratch build links: F24, ppc64(le) - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3541129 Fedora, rawhide, ppc64(le) - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3541133 Fedora rawhide, primary arches - http://koji.fedoraproject.org/koji/taskinfo?taskID=14936002
@Sinny: You said in https://sourceware.org/ml/libc-alpha/2016-07/msg00505.html that the patch wasn't working in rawhide, so why are you proposing it as a fix? I'll go with a temporary setarch solution until a proper patch exists.
(In reply to Jan Synacek from comment #8) > @Sinny: You said in > https://sourceware.org/ml/libc-alpha/2016-07/msg00505.html that the patch > wasn't working in rawhide, so why are you proposing it as a fix? https://sourceware.org/ml/libc-alpha/2016-07/msg00505.html is later on proposed patch which fails for rawhide, pcc64(le). What I have proposed is to use a previous patch from https://sourceware.org/ml/libc-alpha/2016-07/msg00481.html which works fine.
(In reply to Sinny Kumari from comment #9) > (In reply to Jan Synacek from comment #8) > > @Sinny: You said in > > https://sourceware.org/ml/libc-alpha/2016-07/msg00505.html that the patch > > wasn't working in rawhide, so why are you proposing it as a fix? > > https://sourceware.org/ml/libc-alpha/2016-07/msg00505.html is later on > proposed patch which fails for rawhide, pcc64(le). What I have proposed is > to use a previous patch from > https://sourceware.org/ml/libc-alpha/2016-07/msg00481.html which works fine. For reference, my reply to patch proposed at https://sourceware.org/ml/libc-alpha/2016-07/msg00481 is at https://sourceware.org/ml/libc-alpha/2016-07/msg00483.html
This is now "fixed" in emacs-25.0.95-3.fc25. I will leave this bug open for now.
(In reply to Jan Synacek from comment #11) > This is now "fixed" in emacs-25.0.95-3.fc25. I will leave this bug open for > now. Thanks for fixing it. Note: emacs-25.0.95-3.fc25 build uses patch proposed in c#1 (emacs patch for powerpc) instead from c#6 ( emacs build fix for ppc64(le) arch). With current fix used in emacs-25.0.95-3, on ppc64(le) box user will have to run emacs under setarch -R option to avoid memory consumption issue while running.
Created attachment 1182374 [details] emacs build fix for power architectures As mentioned in C#12, emacs-25.0.95-3.fc25 fixes only build failure issue. Memory issue still exist when a file is opened using emacs. Previously, I was not aware of any package which may run emacs during build process. But yesterday came across git package which seems to call emacs during build process and due to which git on ppc64(le) rawhide are failing. Following is the error log: "emacs -batch -f batch-byte-compile git.el Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el (source)... >>Error occurred processing git.el: error (("Memory exhausted--use C-x s then exit and restart Emacs")) ". Good news is that, we have a final patch for this issue which was proposed by Paul Eggert on emacs bugzilla and seems approved to be included in emcas 25 branch http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24033#11. Using mentioned fix, I have prepared a patch which can be included in Fedora dist-git rawhide branch which is available in bugzilla attachment. Successful scratch build with patch included: Fedora rawhide, Pcc64(le) - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3546218 Fedora rawhide, Primary arches - http://koji.fedoraproject.org/koji/taskinfo?taskID=14966690 Also, to avoid confusion have marked previously proposed patches in this bugzilla as Obsoletes.