Created attachment 266389 [details] build log of emerge emacs When trying to emerge emacs, the build locks up and finally dies while processing .elc elisp files. System complains; <nn>.elc locked by root@clunker.. (pid number): Prompts for user input; (s, q, p, ?); typing any of these characters results in instant termination of the emerge; a kill -9 of the pid has the same effect. I have tried varying USE flags; a full set, a set without `X', a minimal set that looked innocuous enough --only sse sse2 and mmx-- and finally no USE flags at all (!) on a freshly installed system, bare but for kernel sources and grub. The results were always the same. The two gentoo boxes in my office; versions 10.1 and 11.0 showed no difference.
Created attachment 266391 [details] output of emerge --info =app-editors/emacs-23.2-r2
Looks like a parallel make failure to me. You can see in the build.log that it compiles some files twice: Compiling /var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2/src/../lisp/select.el Wrote /var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2/lisp/select.elc [...] Compiling ../lisp/select.el I see this behaviour in my logs too, however, it doesn't lock up for me. The problem should be fixed in any case. Can you try to compile it with MAKEOPTS="-j1" to verify this hypothesis?
Created attachment 266491 [details, diff] emacs-23.2-parallel-make.patch Does attached patch fix the problem? AFAIK, make uses a simple string comparison for paths. Therefore, it won't recognise $(lispsource)select.elc and ../lisp/select.elc as identical.
Changing the makeopts to single compilation gave no improvement; the system still asks for user input; after that it dies; albeit with a different error message; could not find leim/quail/.#TONEPY.el I can attach another build log, if that would be any help. > > Can you try to compile it with MAKEOPTS="-j1" to verify this hypothesis?
I inserted this patch at /var/tmp/portage/app-editors/emacs-23.2-r2/work/patch but to no avail; that is probably not the right way. Where do I put your brainchild, and must I diff it? > Created attachment 266491 [details, diff] > emacs-23.2-parallel-make.patch > > Does attached patch fix the problem? >
(In reply to comment #4) > Changing the makeopts to single compilation gave no improvement; > the system still asks for user input; after that it dies; > albeit with a different error message; > could not find leim/quail/.#TONEPY.el Strange, I haven't seen such kind of problems before. On what type of filesystem is your PORTAGE_TMPDIR? (In reply to comment #5) > I inserted this patch at > /var/tmp/portage/app-editors/emacs-23.2-r2/work/patch > > but to no avail; that is probably not the right way. > Where do I put your brainchild, and must I diff it? The standard way would be to do an "ebuild unpack", then apply the patch, and continue compilation with "ebuild compile". You can also put it into the patch dir that you mentioned above (after unpack), in which case you must rename the patch to something like 06_all_parallel-make.patch .
(In reply to comment #6) Plain vanilla ext3 > Strange, I haven't seen such kind of problems before. On what type of > filesystem is your PORTAGE_TMPDIR?
After the unpack in app-editors/emacs I copied the patch file to /var/tmp/portage... under the name that you suggested, then ran the ebuild compile. Mort Subite!--the compilation went immediately to the trouble spot and died. Do you think that Stallman dude will ever forgive us? > The standard way would be to do an "ebuild unpack", then apply the patch, and > continue compilation with "ebuild compile". > You can also put it into the patch dir that you mentioned above (after unpack), > in which case you must rename the patch to something like > 06_all_parallel-make.patch .
(In reply to comment #8) > After the unpack in app-editors/emacs I copied the patch file > to /var/tmp/portage... under the name that you suggested, then > ran the ebuild compile. Mort Subite!--the compilation went immediately > to the trouble spot and died. And the patch was applied? Under "Applying various patches (bugfixes/updates) ..." the filename should be listed. Could you attach the new build.log please?
Created attachment 266549 [details] build log of emerge emacs; failed patch
If neccessary, I will post you the build.log as well, but a cursory glance showed that your patch was not listed. What can I do? -- the patchfile is present in the right directory. The two files present are numbered 01 and 02 respectively. I have renamed the patchfile to 03_all_parallel-make.patch but that didn't help either > And the patch was applied? Under "Applying various patches (bugfixes/updates) > ..." the filename should be listed. > > Could you attach the new build.log please?
Later: I have edited the Makefile.in by hand, guided by your patchfile. after a make clean in the src tree, I performed another unpack compile. Compilation failed again; verified the Makefile.in, which showed the edits, so I must assume, that it has not been overwritten. All for now > > Could you attach the new build.log please?
I fear that "make clean" won't be enough because the Makefile will not be regenerated from Makefile.in. Could you try the following procedure please: $ ebuild /usr/portage/app-editors/emacs/emacs-23.2-r2.ebuild clean $ ebuild /usr/portage/app-editors/emacs/emacs-23.2-r2.ebuild unpack $ cd /var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2 $ patch -p1 < /path/to/emacs-23.2-parallel-make.patch # put real path here $ ebuild /usr/portage/app-editors/emacs/emacs-23.2-r2.ebuild compile
All well up to this point: > $ patch -p1 < /path/to/emacs-23.2-parallel-make.patch # put real path here then patch complains: **** strip count l is not a number maybe an `el' slipped in where a `one` should have been? Anyway, this is probably the reason why the patch didn't take.
(In reply to comment #15) > > $ patch -p1 < /path/to/emacs-23.2-parallel-make.patch # put real path here > > then patch complains: **** strip count l is not a number > > maybe an `el' slipped in where a `one` should have been? Yes it did, namely in your command line: It should be "patch -p1" as in "minus pee one", not "minus pee ell".
I see, never got any further than -p0 while patching. > It should be "patch -p1" as in "minus pee one", not "minus pee ell". Trouble is, the patch still does not catch; complaints: can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option The text leading up to this was: --------------------------- |--- emacs-23.2-orig/src/Makefile.in |+++ emacs-23.2/src/Makefile.in --------------------------- File to patch: <???> I checked location and state of emacs-23.2-parallel-make.patch; the file is in place and it has been untouched.
Additionally, Makefile.in is present in 23.2/src and untouched, but there is no Makefile
(In reply to comment #17) > can't find file to patch at input line 3 > Perhaps you used the wrong -p or --strip option > The text leading up to this was: > --------------------------- > |--- emacs-23.2-orig/src/Makefile.in > |+++ emacs-23.2/src/Makefile.in > --------------------------- Your working directory was ${S}, i.e. /var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2 when you executed the patch command?
In principle, yes, but unfortunately, the entire /var/tmp/portage tree got wiped after the execution of all five commands! I re-emerged emacs, then aplied the ebuilds and the patch, which was accepted this time, and performed the ebuild compile. I am really sorry, Ulrich, but compilation died again at the point where leim could not find .#TONEPY.el. > Your working directory was ${S}, i.e. > /var/tmp/portage/app-editors/emacs-23.2-r2/work/emacs-23.2 when you executed > the patch command?
I double checked Makefile.in, and found evidence that your patch has been inserted, and all object code younger than the three Makefiles, so I must assume that the patched file has been executed
Curiouser and curiouser! In spite of all the moaning and groaning there is a WORKING executable in emacs/src; I fired it up --looked healthy-- edited a file and when I tried to save it under another name the same pathology showed; <name> locked by root@<name_computer> ... (pid number): (s, q, p etc. This strongly suggests, that indeed an exotic writing permission is bogging the system down. And how on earth can a dying ebuild complete a linking process and deliver an executable?
Strange problem. I don't know if the following has anything to do with it, but one thing I was wondering about: ...s-23.2/lisp/select.elc locked by root@Les_Six@... (pid 15533): (s, q, p, ?)? Why are there two @ signs? Does your hostname contain an @ sign?
Juergen, you nailed it! Indeed an `at` had slipped into /etc/hosts; has been removed, and after that emacs compiled straight out of the box, without patching or anything. I have toggled the hostname a couple of times, and everytime an @ appeared in the hostname, the emacs build broke. The question remains, of course, why the emacs build is sensitive to this kind of blooper --all other apps have compiled without a glitch up to this point (If only they had complained a bit more!). > Why are there two @ signs? Does your hostname contain an @ sign?
Closing this bug as invalid: Hostnames must only contain characters a-z, 0-9 and the hyphen, see RFC 952. (In reply to comment #24) > The question remains, of course, why the emacs build is sensitive to this > kind of blooper Yes, and I'm going to ask Emacs upstream if anything can be done about this.
And that last address is, of course, the expected result while one is fighting the Martian Death Flu. Sorry Ulrich, I was editing one message too many, and the addressees got mixed up. Straight to bed with a hot toddy!
