[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
From: |
Eli Zaretskii |
Subject: |
bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode |
Date: |
Fri, 11 Mar 2016 16:31:52 +0200 |
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Fri, 11 Mar 2016 06:17:45 -0500
> Cc: 22975@debbugs.gnu.org
>
> It appears that Emacs tries to display the “Using load-path …” message, calls
> echo_area_display, display_echo_area, with_echo_area_buffer,
> display_echo_area_1, resize_mini_window, and grow_mini_window, which then uses
> call3 (Qwindow_resize_root_window_vertically, …)
> but since we haven’t loaded window.el yet, there’s no function definition and
> we raise a signal, quitting out of loadup and trying to display a message.
I'm not sure I follow: message calls message3_nolog, which should have
done this:
void
message3_nolog (Lisp_Object m)
{
struct frame *sf = SELECTED_FRAME ();
if (FRAME_INITIAL_P (sf))
message_to_stderr (m);
Is FRAME_INITIAL_P not doing it job in this case?
And just so I'm on the right page here: the "Loading foo..." messages
that loadup.el displays are shown where in this case? written to
stderr or displayed in the echo area?
> As to why normal temacs doesn’t show the problem: The load path displayed for
> a normal temacs contains one directory, but for a CANNOT_DUMP emacs it
> contains several; in my tests, resize_mini_window computed the height needed
> as one line for the former and six lines for the latter, so only in the
> latter case did grow_mini_window need to get called.
I think temacs should write these messages to stderr, so the whole
resize_mini_window rigmarole shouldn't get called at all. What am I
missing?
> If I mess around with installation prefix length, window size, and font size,
> I can get the CANNOT_DUMP emacs to start properly (but with unreadably tiny
> characters); and if I make my terminal window quite narrow, I can get a
> normal temacs to get into some kind of error loop (not the same failure mode
> but probably a similar root cause). So it’s not just the CANNOT_DUMP setting
> that’s causing the problem.
Error loop that displays what messages?
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Ken Raeburn, 2016/03/10
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Eli Zaretskii, 2016/03/10
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Eli Zaretskii, 2016/03/10
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Ken Raeburn, 2016/03/11
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode,
Eli Zaretskii <=
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Ken Raeburn, 2016/03/11
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Eli Zaretskii, 2016/03/11
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Kenneth Raeburn, 2016/03/11
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Andreas Schwab, 2016/03/11
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Eli Zaretskii, 2016/03/11
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Eli Zaretskii, 2016/03/12
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Ken Raeburn, 2016/03/12
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, martin rudalics, 2016/03/13
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, Eli Zaretskii, 2016/03/13
- bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode, martin rudalics, 2016/03/13