[ebuild R ] app-editors/emacs-22.1-r1 USE="X alsa gif gtk* hesiod jpeg motif png sound spell tiff xpm -Xaw3d -gzip-el -source -toolkit-scroll-bars" 0 kB Fails to build on HPPA: Loading replace... Loading abbrev... Loading buff-menu... Loading fringe... Loading image... Loading international/fontset... Loading dnd... Loading mwheel... Loading tool-bar... Loading x-dnd... ((56871 . 10049) (11616 . 0) (620 . 66) 79304 166484 (68 . 8) (18 . 12) (5582 . 2041)) Loading emacs-lisp/float-sup... ((56901 . 10019) (11620 . 0) (620 . 66) 79359 166484 (69 . 9) (18 . 12) (5584 . 2039)) Loading vc-hooks... Loading ediff-hook... Loading tooltip... ((58206 . 8714) (11762 . 0) (621 . 65) 80654 166535 (71 . 7) (18 . 12) (5655 . 1 968)) make[1]: *** [emacs] Segmentation fault make[1]: Leaving directory `/mnt/alt/portage-tmp/portage/app-editors/emacs-22.1- r1/work/emacs-22.1/src' make: *** [src] Error 2 * * ERROR: app-editors/emacs-22.1-r1 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_compile * ebuild.sh, line 990: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * emacs-22.1-r1.ebuild, line 140: Called die * * emake failed * If you need support, post the topmost build error, and the call stack if rele vant. * A complete build log is located at '/keeps/gentoo/emergelogs/elmer/app-editor s:emacs-22.1-r1:20070924-181729.log'. dmesg shows it is ./temacs that is segfaulting: [534960.984000] do_page_fault() pid=10294 command='temacs' type=15 address=0x000 01221 [534960.984000] [534960.984000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [534960.984000] PSW: 00000000000001001111111100001111 Not tainted [534960.984000] r00-03 0004ff0f 00001001 4170bda7 0030c468 [534960.984000] r04-07 00000001 00000004 000000b0 00311468 [534960.984000] r08-11 00311468 00311468 00311468 00311468 [534960.984000] r12-15 00310468 40020000 00330458 00330508 [534960.984000] r16-19 00000000 0030c468 00311468 00000001 [534960.984000] r20-23 00000006 00000000 00000001 417c0b8c [534960.984000] r24-27 00000001 00000001 00000004 001b9c68 [534960.984000] r28-31 00000000 00000000 fb06f8c0 4170bdb7 [534960.984000] sr00-03 00000000 00000000 00000000 00000024 [534960.984000] sr04-07 00000024 00000024 00000024 00000024 [534960.984000] [534960.984000] VZOUICununcqcqcqcqcqcrmunTDVZOUI [534960.984000] FPSR: 00001100001111010011100000000000 [534960.984000] FPER1: 00000000 [534960.984000] fr00-03 0c3d380000000000 0000000000000000 0000000000000000 0000 000000000000 [534960.984000] fr04-07 3fe999999999999a 3fed4723aafff36a 3c91a62633145c07 3ff0 000000000000 [534960.984000] fr08-11 3ff0000000000000 0000000000000000 0000000000000000 3ff9 21fb54442d18 [534960.984000] fr12-15 00328cab10635810 00534b631017de08 40023a5000000080 11b6 420000000000 [534960.984000] fr16-19 ffffff9c105d3810 0000000f11b64208 0000000b00000000 1060 77f3106077f2 [534960.984000] fr20-23 105f901000000000 5555555510172258 40186ed8000000e1 4018 27d4b827fa19 [534960.984000] fr24-27 ffffffff00000000 3ff5bf0a8b145769 3ec04ea635580000 beb7 f7d1cf79abca [534960.984000] fr28-31 3e3ee67e8938c386 3ff000e008000000 3ff0000000000000 3ff0 000000000000 [534960.984000] [534960.984000] IASQ: 00000024 00000024 IAOQ: 4170bdbf 4170bdc3 [534960.984000] IIR: 483f0440 ISR: 00000024 IOR: 00001221 [534960.984000] CPU: 0 CR30: 20784000 CR31: 1065c000 [534960.984000] ORIG_R28: 00000001 [534960.984000] IAOQ[0]: 0x4170bdbc [534960.984000] IAOQ[1]: 0x4170bdc0 [534960.984000] RP(r2): 0x4170bda4
Created attachment 131818 [details] emerge --info
Created attachment 131819 [details] app-editors:emacs-22.1-r1:20070924-181729.log.gz (gzipped build log)
Does one of emacs-cvs-22.1.50-r1 or emacs-cvs-22.1.50_p20070829 build properly?
(In reply to comment #3) > Does one of emacs-cvs-22.1.50-r1 or emacs-cvs-22.1.50_p20070829 build properly? jer, could you please check so we have less to investigate?
(In reply to comment #3) > Does one of emacs-cvs-22.1.50-r1 or emacs-cvs-22.1.50_p20070829 build properly? Both build properly with USE=-gtk, and both fail with USE=gtk.
The last message we see in the build log (attachment #131819 [details]) is the output of a successful garbage collection, line 216 of loadup.el. Next message would be "Finding pointers to doc strings..." output in line 253. So the problem should be somewhere in between. The only thing that could be related to gtk is in line 228 where precompute-menubar-bindings is called, which in turn calls x-popup-menu. Could you run "./temacs -batch -l loadup dump" (in ${S}/src) again under gdb, to get a stack trace?
Actually it doesn't seem to fail outside of the sandbox: elmer /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-22.1.50-r1/work/emacs-22/src # ./temacs -batch -l loadup dump Loading loadup.el (source)... Using load-path (/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-22.1.50-r1/work/emacs-22/lisp) Loading emacs-lisp/byte-run (source)... Loading emacs-lisp/backquote (source)... Loading subr (source)... Loading version.el (source)... Loading widget (source)... Loading custom (source)... Loading emacs-lisp/map-ynp (source)... Loading env (source)... Loading cus-start (source)... Loading international/mule (source)... Loading international/mule-conf.el (source)... Loading format (source)... Loading bindings (source)... Loading files.el (source)... Loading cus-face.el (source)... Loading faces.el (source)... (require cl) while preparing to dump elmer /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-22.1.50-r1/work/
(In reply to comment #7) > Actually it doesn't seem to fail outside of the sandbox: The Emacs ebuilds have SANDBOX_ON=0, so that shouldn't be the reason. Have you already tried with "emake -j1"?
(In reply to comment #8) > Have you already tried with "emake -j1"? Same result.
(In reply to comment #8) > > Actually it doesn't seem to fail outside of the sandbox: > > The Emacs ebuilds have SANDBOX_ON=0, so that shouldn't be the reason. Actually, there might be a difference due a different environment, for example the DISPLAY variable. Could you unset DISPLAY and try the following again: (In reply to comment #6) > Could you run "./temacs -batch -l loadup dump" (in ${S}/src) again under gdb, > to get a stack trace?
Created attachment 134890 [details] gdb bt full
Reported upstream: <http://permalink.gmane.org/gmane.emacs.bugs/16893>
From: Richard Stallman <rms@gnu.org> Reply-to: rms@gnu.org To: Ulrich Mueller <ulm@gentoo.org> CC: bug-gnu-emacs@gnu.org, jer@gentoo.org, emacs@gentoo.org Subject: Re: Emacs 22.1 --with-x-toolkit=gtk build failure on HPPA Date: Thu, 01 Nov 2007 22:06:33 -0400 This sort of problem can only be debugged by people with that sort of machine available. If someone sends us a fix, we can install it, but that is all we can do.
(In reply to comment #13) > This sort of problem can only be debugged by people with that sort > of machine available. Therefore reassigning to HPPA team.
Is this still an issue? I'm asking because you've marked 22.1-r3 stable...
(In reply to comment #15) > Is this still an issue? I'm asking because you've marked 22.1-r3 stable... + epatch "${FILESDIR}/${P}-format-int.patch" With that being the difference, I don't think it would be enough to fix some random HPPA/GTK+ problem. With USE=-gtk, emacs-22 builds and works fine. You'll be very sure to notice when this is not an issue anymore...
But hppa/2007.0/desktop sets USE=gtk, right? I was just wondering why 22.1-r3 was stabilised (we had asked for 21.4-r14 only) if it cannot be built in the default configuration. Of course it would be better if we could fix this bug, but I don't see how the Emacs team could help at the moment. The stack trace shows that something goes very wrong, but doesn't point to any specific place. A major difference between USE=-gtk and USE=gtk is also that the program is threaded for the latter, and different routines for memory allocation are used.
# Jeroen Roovers <jer@gentoo.org> (26 Nov 2007) # emacs doesn't build with USE=gtk (bug #193703) >=app-editors/emacs-22 gtk Until this bug is resolved.
This patch to the ebuild seems to fix it. It's compiler optimisations again, it seems (note that I previously tested with -O2). If you OK this patch I will commit it: jeroen@astrid /keeps/gentoo/cvs/gentoo-x86/app-editors/emacs $ cvs diff emacs-22.1-r3.ebuild Index: emacs-22.1-r3.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/app-editors/emacs/emacs-22.1-r3.ebuild,v retrieving revision 1.2 diff -u -B -r1.2 emacs-22.1-r3.ebuild --- emacs-22.1-r3.ebuild 26 Nov 2007 00:25:47 -0000 1.2 +++ emacs-22.1-r3.ebuild 26 Nov 2007 21:28:01 -0000 @@ -83,7 +83,11 @@ ALLOWED_FLAGS="" strip-flags unset LDFLAGS - replace-flags -O[3-9] -O2 + if use hppa; then + replace-flags -O[3-9] -O + else + replace-flags -O[3-9] -O2 + fi sed -i -e "s/-lungif/-lgif/g" configure* src/Makefile* || die local myconf
> If you OK this patch I will commit it: Go ahead. But, one minor point: > + if use hppa; then > + replace-flags -O[3-9] -O This should be "replace-flags -O[2-9] -O".
(In reply to comment #20) > > If you OK this patch I will commit it: > > Go ahead. But, one minor point: [...] > This should be "replace-flags -O[2-9] -O". That's not so minor. :) Fixed in CVS. p.u.mask removed.
/
> BugsThisDependsOn 203543 What lets you assume that this is the same issue? The incorrect branching in bug 203543 happens for -O1, while the Emacs problem occured for -O[2-3].
(In reply to comment #23) > > BugsThisDependsOn 203543 > > What lets you assume that this is the same issue? What suggests that I do? For all I care, this bug needed to be reopened in order to inventorise gcc -O bugs. Connecting it to the gcc branching bug would certainly help for now even if we would need to re-categorise this bug later. > The incorrect branching in bug 203543 happens for -O1, while the Emacs problem > occured for -O[2-3]. Yes, but there may be more behind it than that, and ruling that out now would be silly.
That didn't fix it.
Is this still an issue in app-editors/emacs-cvs-22.2.91? We are approaching the last pretests for 22.3 so this might be the last chance to fix the bug for Emacs 22.
22.3 did work for me. Can you confirm it's all good ?
app-editors/emacs-cvs-23.0.94 still fails.
With this patch, suggested by ulm on IRC, the build doesn't fail but hangs: --- src/s/gnu-linux.h.orig 2009-05-23 05:43:48.000000000 +0200 +++ src/s/gnu-linux.h 2009-05-28 01:00:24.000000000 +0200 @@ -258,7 +258,7 @@ #if defined __i386__ || defined __sparc__ || defined __mc68000__ \ || defined __alpha__ || defined __mips__ || defined __s390__ \ || defined __arm__ || defined __powerpc__ || defined __amd64__ \ - || defined __ia64__ || defined __sh__ + || defined __ia64__ || defined __sh__ || defined __hppa__ #define GC_SETJMP_WORKS 1 #define GC_MARK_STACK GC_MAKE_GCPROS_NOOPS #ifdef __mc68000__ at: Checking /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/quail/viqr.el ... Checking /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/quail/ECDICT.el ... Saving file /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-list.el... Wrote /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-list.el Updating /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-list.el ... done sed -n '/^[^;]/ p' < /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim/leim-ext.el >> leim-list.el make[1]: Leaving directory `/mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/leim' Compiling /mnt/alt/portage-tmp/portage/app-editors/emacs-cvs-23.0.94/work/emacs-23.0.94/lisp/mh-e/mh-letter.el
(In reply to comment #19) > - replace-flags -O[3-9] -O2 > + if use hppa; then > + replace-flags -O[3-9] -O > + else > + replace-flags -O[3-9] -O2 > + fi I've noticed that for some reason emacs-23.1.ebuild (which was copied from emacs-cvs-23.0.96.ebuild) doesn't do this flag replacement. Probably it should, but I don't remember the history. @hppa: Can you test app-editors/emacs-23.1 with USE=gtk?
Created attachment 201040 [details] app-editors:emacs-23.1:20090809-141014.log.gz [hppa,success] (In reply to comment #30) > (In reply to comment #19) > > - replace-flags -O[3-9] -O2 > > + if use hppa; then > > + replace-flags -O[3-9] -O > > + else > > + replace-flags -O[3-9] -O2 > > + fi > > I've noticed that for some reason emacs-23.1.ebuild (which was copied from > emacs-cvs-23.0.96.ebuild) doesn't do this flag replacement. Probably it should, > but I don't remember the history. > > @hppa: Can you test app-editors/emacs-23.1 with USE=gtk? Seems to have worked out quite well.
So the problem is gone in 23.1, and for 22.3 there is a workaround in place. Therefore closing.
