GNU bug report logs - #58771
29.0.50; context submenu can not click when run emacs lucid build.

Previous Next

Package: emacs;

Reported by: Feng Shu <tumashu <at> 163.com>

Date: Tue, 25 Oct 2022 05:45:01 UTC

Severity: normal

Merged with 57320, 57518, 59733

Found in version 29.0.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #44 received at 58771 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Mike Kupfer <kupfer <at> rawbw.com>
Cc: Feng Shu <tumashu <at> 163.com>, Stephen Berman <stephen.berman <at> gmx.net>,
 58771 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
Subject: Re: bug#58771: 29.0.50; context submenu can not click when run
 emacs lucid build.
Date: Wed, 11 Jan 2023 17:47:18 +0800
Mike Kupfer <kupfer <at> rawbw.com> writes:

> I don't even need to rerun configure.  I just added a debug fprintf to
> pop_up_menu(), rebuilt Emacs, and the problem vanished.

Would you please send me the two different binaries?

  (Off-list, please, if you're worried about the binaries containing
  private information.)

> I still have the binary that fails.  On a hunch, I added a breakpoint at
> the start of pop_up_menu().  When the breakpoint triggered, I checked
> the value of lucid__menu_grab_keyboard.  gdb says
>
> (gdb) print lucid__menu_grab_keyboard
> $2 = false
>
> Yet *Help* says that the value of lucid--menu_grab_keyboard is t.
>
> If I do 
>
>   M-: (setq lucid--menu_grab_keyboard t)
>
> and press F10, gdb says lucid__menu_grab_keyboard is still false.
>
> I did a little more poking around with gdb and found that
> lucid__menu_grab_keyboard moves around inside "globals".
>
> Broken binary:
>
> (gdb) print &globals.f_lucid__menu_grab_keyboard
> $3 = (_Bool *) 0x555555d54a98 <globals+4152>
>
> Working binary:
>
> (gdb) print &globals.f_lucid__menu_grab_keyboard
> $2 = (_Bool *) 0x555555d54ad0 <globals+4208>
>
> This strikes me as more than a little odd.  Given that all I did was
> add a couple fprintfs, I'd expect the layout of "globals" to stay the
> same.

I have a hunch.  If you touch globals.h in src, does it result in files
under the lwlib directory being rebuilt?

My guess is globals.h changed but lwlib was not incrementally rebuilt.
I guess this means lwlib/*.o has to be made to depend on
$(top_builddir)/globals.stamp or somesuch.  Thanks.




This bug report was last modified 2 years and 132 days ago.

Previous Next


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