* bug#24974: CANNOT_DUMP build assumes Emacs is already installed
@ 2016-11-20 21:38 Paul Eggert
2016-12-01 0:36 ` Glenn Morris
0 siblings, 1 reply; 4+ messages in thread
From: Paul Eggert @ 2016-11-20 21:38 UTC (permalink / raw
To: 24974
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#24974: CANNOT_DUMP build assumes Emacs is already installed
2016-11-20 21:38 bug#24974: CANNOT_DUMP build assumes Emacs is already installed Paul Eggert
@ 2016-12-01 0:36 ` Glenn Morris
2016-12-01 1:03 ` Daniel Colascione
0 siblings, 1 reply; 4+ messages in thread
From: Glenn Morris @ 2016-12-01 0:36 UTC (permalink / raw
To: Paul Eggert; +Cc: 24974
How about:
--- a/src/lread.c
+++ b/src/lread.c
@@ -4296,6 +4296,8 @@ BUFFER is the buffer to evaluate (nil means use current buffer),
#endif
normal = PATH_LOADSEARCH;
+ if (!NILP (Vinstallation_directory)) normal = PATH_DUMPLOADSEARCH;
+
#ifdef HAVE_NS
lpath = decode_env_path (0, loadpath ? loadpath : normal, 0);
#else
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#24974: CANNOT_DUMP build assumes Emacs is already installed
2016-12-01 0:36 ` Glenn Morris
@ 2016-12-01 1:03 ` Daniel Colascione
2016-12-19 18:35 ` Glenn Morris
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Colascione @ 2016-12-01 1:03 UTC (permalink / raw
To: Glenn Morris; +Cc: Paul Eggert, 24974
On Wed, Nov 30 2016, Glenn Morris wrote:
> How about:
>
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -4296,6 +4296,8 @@ BUFFER is the buffer to evaluate (nil means use current buffer),
> #endif
>
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#24974: CANNOT_DUMP build assumes Emacs is already installed
2016-12-01 1:03 ` Daniel Colascione
@ 2016-12-19 18:35 ` Glenn Morris
0 siblings, 0 replies; 4+ messages in thread
From: Glenn Morris @ 2016-12-19 18:35 UTC (permalink / raw
To: 24974-done
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-12-19 18:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-20 21:38 bug#24974: CANNOT_DUMP build assumes Emacs is already installed Paul Eggert
2016-12-01 0:36 ` Glenn Morris
2016-12-01 1:03 ` Daniel Colascione
2016-12-19 18:35 ` Glenn Morris
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.