bug#58771: 29.0.50; context submenu can not click when run emacs lucid build.

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Mike Kupfer <kupfer@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.