GNU bug report logs - #24974
CANNOT_DUMP build assumes Emacs is already installed

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#24974: closed (Re: bug#24974: CANNOT_DUMP build assumes Emacs
 is already installed)
Date: Mon, 19 Dec 2016 18:36:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#24974: CANNOT_DUMP build assumes Emacs is already installed

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 24974 <at> debbugs.gnu.org.

-- 
24974: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24974
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Glenn Morris <rgm <at> gnu.org>
To: 24974-done <at> debbugs.gnu.org
Subject: Re: bug#24974: CANNOT_DUMP build assumes Emacs is already installed
Date: Mon, 19 Dec 2016 13:35:47 -0500

Version: 26.1

Daniel Colascione wrote:

>>    normal = PATH_LOADSEARCH;
>> +  if (!NILP (Vinstallation_directory)) normal = PATH_DUMPLOADSEARCH;
>> +
>>  #ifdef HAVE_NS
>>    lpath = decode_env_path (0, loadpath ? loadpath : normal, 0);
>>  #else
>
> I changed a lot of this code in my portable dumper patch.  The new code
> works fine for me with CANNOT_DUMP uninstalled. We can split this change
> (and the corresponding loadup.el changes) out from the rest of the patch
> pretty easily, I think.

I look forward to those changes, but in the meantime I installed my
one-liner as 504e384, since it seems like an improvement, and can't eg
make merging any harder.

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Subject: CANNOT_DUMP build assumes Emacs is already installed
Date: Sun, 20 Nov 2016 13:38:27 -0800

The CANNOT_DUMP build procedure is confused: it assumes that the current version 
of Emacs is already installed, and Emacs builds can fail (or be subtly wrong) 
when this assumption is not true. To reproduce the problem, pick a directory 
that doesn't exist ("/tmp/prefix" in the example below) and configure and build 
this way:

./configure --prefix=/tmp/prefix CANNOT_DUMP=yes
make bootstrap

On my platform (Ubuntu 16.04 x86-64) the build fails as follows:

ln -f temacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[3]: Entering directory '/home/eggert/src/gnu/emacs/static-checking/lisp'
  ELC      emacs-lisp/macroexp.elc
Warning: Lisp directory '/tmp/prefix/share/emacs/26.0.50/lisp': No such file or 
directory
Cannot open load file: No such file or directory, loadup.el
Makefile:282: recipe for target 'emacs-lisp/macroexp.elc' failed

The full command that fails (abbreviated "ELC emacs-lisp/macrorexp.elc above) is:

EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l 
autoload \
   --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
   --eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name 
\"calendar/cal-loaddefs.el\")))" \
   -f batch-update-autoloads ./calendar

Running strace on this command reveals that it attempts to open only:

/tmp/prefix/share/emacs/26.0.50/lisp/loadup.el.elc
/tmp/prefix/share/emacs/26.0.50/lisp/loadup.el.el
/tmp/prefix/share/emacs/26.0.50/lisp/loadup.el

and it never attempts to open loadup.el in the current directory, which is 
what's needed here.

By the way, why does Emacs try to open ".../loadup.el.elc"? Isn't that a waste 
of time?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.