Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Loading /usr/libexec/emacs/21.4/i686-pc-linux-gnu/fns-21.4.2.el (source)... While compiling toplevel forms in file /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent/wisent-calc.el: ** variable `semantic-format-tag-functions' obsoletes, but isn't alias of `semantic-token->text-functions' ** variable `semantic-tag-expand-function' obsoletes, but isn't alias of `semantic-expand-nonterminal' ** variable `semantic--parse-table' obsoletes, but isn't alias of `semantic-toplevel-bovine-table' ** variable `semantic--buffer-cache' obsoletes, but isn't alias of `semantic-toplevel-bovine-cache' ** variable `semantic--before-fetch-tags-hook' obsoletes, but isn't alias of `semantic-before-toplevel-bovination-hook' ** variable `semantic-working-type' obsoletes, but isn't alias of `semantic-bovination-working-type' Wrote /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent/wisent-calc.elc While compiling toplevel forms in file /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent/wisent-java.el: ** variable `semantic-format-tag-functions' obsoletes, but isn't alias of `semantic-token->text-functions' ** variable `semantic-format-tag-custom-list' obsoletes, but isn't alias of `semantic-token->text-custom-list' ** variable `semantic-format-face-alist' obsoletes, but isn't alias of `semantic-face-alist' ** variable `semantic-imenu-expand-type-members' obsoletes, but isn't alias of `semantic-imenu-expand-type-parts' ** variable `semantic-imenu-bucketize-type-members' obsoletes, but isn't alias of `semantic-imenu-bucketize-type-parts' ** variable `semantic-imenu-expandable-tag-classes' obsoletes, but isn't alias of `semantic-imenu-expandable-token' ** variable `semantic-step-at-tag-classes' obsoletes, but isn't alias of `semantic-step-at-token-ids' ** variable `senator-step-at-start-end-tag-classes' obsoletes, but isn't alias of `senator-step-at-start-end-token-ids' ** variable `senator-add-log-tags' obsoletes, but isn't alias of `senator-add-log-tokens' !! End of file during parsing Wrote /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent/wisent-java-tags.elc While compiling toplevel forms in file /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent/wisent-python.el: ** `(= last-pos (point))' called for effect Wrote /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent/wisent-python.elc Done make[2]: *** [languages] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/wisent' make[1]: *** [wisent] Error 2 make[1]: Leaving directory `/var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic' make: *** [semantic] Error 2 !!! ERROR: app-emacs/cedet-1.0_pre4 failed.
Created an attachment (id=123080) [details] emerge --info
I've added option -j1 to emake, does this fix the problem?
(In reply to comment #2) > I've added option -j1 to emake, does this fix the problem? No, this is not a parallel build issue. The error is reproducible even with -j1.
I cannot reproduce it here. For me, the package installs cleanly with Emacs 21.4 or 22.1. Could you please describe (step by step) how to reproduce the problem?
(In reply to comment #4) > Could you please describe (step by step) how to reproduce the problem? Difficult to say, as I only did an emerge -uavND world. > I cannot reproduce it here. For me, the package installs cleanly with Emacs > 21.4 or 22.1. I just found out I had two emacs versions installed as well, 21.4-r12 and 22.1. I had been using 21, and after switching to 22 cedet emerged successfully. As the package now merged cleanly for me, I'm not eager to invest too much effort into finding out the cause for this. Can you suggest any method short of installing all dependencies in a chrooted stage3 to locate the source of this problem here?
(In reply to comment #5) > I just found out I had two emacs versions installed as well, 21.4-r12 and 22.1. > I had been using 21, and after switching to 22 cedet emerged successfully. No problems here, too. > As the package now merged cleanly for me, I'm not eager to invest too much > effort into finding out the cause for this. That is sad. > Can you suggest any method short of > installing all dependencies in a chrooted stage3 to locate the source of this > problem here? There is a guide in http://www.gentoo.org/proj/en/base/x86/chroot.xml Could you please switch back to Emacs 21 and try again. Maybe this was a random one-time failure.
(In reply to comment #6) > There is a guide in http://www.gentoo.org/proj/en/base/x86/chroot.xml Do you really suggest trying this? It seemed rather a long shot to me. OK, I think I can try this, but I fear I might end up at a clean emerge and none the wiser as to what is causing the problem in my productive environment. > Could you please switch back to Emacs 21 and try again. Maybe this was a > random one-time failure. I already tried, and got the same failure again.
(In reply to comment #7) > Do you really suggest trying this? It seemed rather a long shot to me. OK, I > think I can try this, but I fear I might end up at a clean emerge and none the > wiser as to what is causing the problem in my productive environment. As I feared. cedet emerged cleanly, in a starge3 with my make.conf and package.use copied from the outside. Comparing the CONTENTS list of e.g. the emcas package inside the chroot and outside, I find different checksums. And now? I'm running out of ideas. I guess if I were to emerge -e cedet on the outside, it would probably merge cleanly as well. But as I got it working with emacs 22 there is nothing to gain, and we'd lose the one setup where I can reproduce the problem.
Created an attachment (id=123105) [details] cedet-1.0_pre4-wisent-compile.patch Please try attached patch. It compiles wisent's language files separately, instead of in one path. I still cannot reproduce the problem myself, though.
(In reply to comment #9) > Please try attached patch. It compiles wisent's language files separately, > instead of in one path. I added an " || exit 1" to the command inside the loop to ensure no errors go unnoticed. With this wisent compiled, but bovine failed next. Doing the same there for languages as well still causes it to fail, but I think now the error message might be useful: for file in semantic-c.el semantic-el.el semantic-make.el semantic-scm.el semantic-java.el erlang-edoc.el semantic-erlang.el; do "/usr/bin/emacs" -batch --no-site-file -l languages-compile-script -f batch-byte-compile $file || exit 1; done ... Wrote /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/bovine/semantic-java.elc Done Source file `/usr/share/emacs/site-lisp/cedet/ede/ede.el' newer than byte-compiled file Loading /usr/libexec/emacs/21.4/i686-pc-linux-gnu/fns-21.4.2.el (source)... Source file `/usr/share/emacs/site-lisp/cedet/ede/ede-speedbar.el' newer than byte-compiled file While compiling toplevel forms in file /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/bovine/erlang-edoc.el: ** variable ... `semantic-bovination-working-type' !! End of file during parsing Done make[2]: *** [languages] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/bovine' make[1]: *** [bovinator] Error 2 make[1]: Leaving directory `/var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic' make: *** [semantic] Error 2 As you can see, the cedet version being compiled uses files already installed. I guess that's a bad idea. The LOADPATH from which languages-compile-script is generated is given in the Makefile as LOADPATH= ../../common/ ../ ../../eieio/ ../wisent/ ../../speedbar/ You can see there is no ede mentioned there. I'm not sure where this dependency on ede comes from. After adding ../../ede, though, I still get an error: Wrote /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/bovine/semantic-java.elc Done Loading /usr/libexec/emacs/21.4/i686-pc-linux-gnu/fns-21.4.2.el (source)... While compiling toplevel forms in file /var/tmp/portage/app-emacs/cedet-1.0_pre4/work/cedet-1.0pre4/semantic/bovine/erlang-edoc.el: ** variable ... `semantic-bovination-working-type' !! End of file during parsing Done Looks like emacs really doesn't like this file, or any of its requirements.
I can now reproduce your problem: eselect emacs set emacs-21 emerge =cedet-1.0_pre3 emerge =cedet-1.0_pre4 Many Makefiles (wisent, bovine and others) call Emacs with --no-site-file but with without -q. So this may be the problem.
(In reply to comment #11) > Many Makefiles (wisent, bovine and others) call Emacs with --no-site-file but > with without -q. -batch implies -q.
(In reply to comment #11) > I can now reproduce your problem: > > eselect emacs set emacs-21 > emerge =cedet-1.0_pre3 > emerge =cedet-1.0_pre4 Yep, that fails for me, too. I've put 1.0_pre4 in package.mask until we find a solution.
So what should we do? One way could be to use NEED_EMACS=22, but that is not a proper solution. It surely is a bug if it takes the files from the installed system and not the WORKDIR...upstream should have a look at this.
Created an attachment (id=123157) [details] cedet-1.0_pre4-semantic-makefile.patch I could make it compile by doing "make -k" followed by "make" which might indicate that some dependency is missing in the Makefiles. However, we probably don't want to add such a (dirty) workaround to the ebuild. After some further investigation I believe that "bovinator" is needed as a prerequisite for compiling "wisent". Please try attached patch.
(In reply to comment #15) > Please try attached patch. Compiled cleanly. However it still gives me messages like this: Source file `/usr/share/emacs/site-lisp/cedet/ede/ede.el' newer than byte-compiled file So it is still accessing files that are part of the merged version.
(In reply to comment #16) > > Please try attached patch. > Compiled cleanly. Installed. > However it still gives me messages like this: > Source file `/usr/share/emacs/site-lisp/cedet/ede/ede.el' newer than > byte-compiled file > So it is still accessing files that are part of the merged version. Thank you for reporting and for your help in testing. Could you please also report the whole issue upstream?
(In reply to comment #17) > Could you please also report the whole issue upstream? I did that.
(In reply to comment #18) > > Could you please also report the whole issue upstream? > I did that. Seems your report got lost, so I've reported it again: <http://thread.gmane.org/gmane.emacs.semantic/1379>
(In reply to comment #19) > Seems your report got lost, Indeed. I sent it to cedet-devel on Wed, 27 Jun 2007 with subject "cedet 1.0pre4 build issues", but it never appeared in their archives. Thanks for checking! My original post had some info about the build using files from the installed version as observed in comment 10, which your post doesn't mention. I just resubmitted this issue as well: http://sf.net/tracker/index.php?func=detail&aid=1790014&group_id=17886&atid=117886
(In reply to comment #20) > My original post had some info about the build using files from the installed > version as observed in comment 10, which your post doesn't mention. Could this be related to bug #191341, i.e. does the patch from attachment #130225 [details] fix the issue you had mentioned in comment #16?
(In reply to comment #21) > Could this be related to bug #191341, i.e. does the patch from attachment > #130225 [edit] fix the issue you had mentioned in comment #16? Yes, that patch solves the references to the installed ede version as well. How about the reverse? Does adding ../../ede/ to LOADPATH in the Makefiles of wisent and bovine solve the issue from bug #191341 as well?
(In reply to comment #22) > How about the reverse? Does adding ../../ede/ to LOADPATH in the Makefiles of > wisent and bovine solve the issue from bug #191341 as well? I found out that I could reproduce this truncation described in bug #191341 comment #23 with this addition to LOADPATH. Seems like your patch is the better solution. I'll add a comment to the upstream bug report I created.
