Summary: | app-editors/emacs-22.1-r1 - USE=gtk build failure on HPPA | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | HPPA Porters <hppa> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gnu-emacs |
Priority: | High | ||
Version: | 2007.0 | ||
Hardware: | HPPA | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=839405 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
app-editors:emacs-22.1-r1:20070924-181729.log.gz (gzipped build log) gdb bt full app-editors:emacs-23.1:20090809-141014.log.gz [hppa,success] |
Description
Jeroen Roovers (RETIRED)
2007-09-25 00:50:00 UTC
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. |