bug#36929: 27.0.50; Build on master broken

bug#36929: 27.0.50; Build on master broken

[Philipp]

When running `make':

  CC       pdumper.o
pdumper.c:2700:3: error: "Lisp_Hash_Table changed. See CHECK_STRUCTS comment in
      config.h."
# error "Lisp_Hash_Table changed. See CHECK_STRUCTS comment in config.h."
  ^
1 error generated.
make[1]: *** [pdumper.o] Error 1
make: *** [src] Error 2

I guess this is due to commit c74da403aa95ec67598c41aa4f1b97975391135b.
The commit only changes comments in lisp.h, but also includes a
functional change to the hash table binary format, so maybe the dumper
needs to be updated.

Should we maybe define CHECK_STRUCTS unconditionally to prevent issues
like this?


In GNU Emacs 27.0.50 (build 4, x86_64-apple-darwin18.6.0, NS appkit-1671.50 Version 10.14.5 (Build 18F132))
 of 2019-06-16
Repository revision: 7e53f4f2da0ec6dd2284db39c00657dec2566886
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1671
System Description:  Mac OS X 10.14.6

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-g3 -O1 -fsanitize=address
 -fsanitize=undefined -fno-omit-frame-pointer''

Configured features:
NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS
JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs
format-spec rfc822 mml mml-sec epa epg epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton
derived edmacro kmacro pcase ffap thingatpt url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars
subr-x rx cl-extra help-mode easymenu gnutls puny seq byte-opt gv
bytecomp byte-compile cconv dbus xml cl-loaddefs cl-lib elec-pair
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 59978 5503)
 (symbols 48 7864 1)
 (strings 32 20108 1716)
 (string-bytes 1 663507)
 (vectors 16 11562)
 (vector-slots 8 143774 9468)
 (floats 8 23 12)
 (intervals 56 200 0)
 (buffers 992 11))

bug#36929: 27.0.50; Build on master broken

[Mattias Engdegård]

Philipp skrev:

> I guess this is due to commit c74da403aa95ec67598c41aa4f1b97975391135b. 

If that change it is to blame, it was fixed later on; I can bootstrap 6c1d0d53b3 on macOS and Linux.
Can you confirm?

bug#36929: 27.0.50; Build on master broken

[Eli Zaretskii]

> From: Philipp <p.stephani2@gmail.com>
> Date: Mon, 05 Aug 2019 10:24:24 +0200
> 
> 
> When running `make':
> 
>   CC       pdumper.o
> pdumper.c:2700:3: error: "Lisp_Hash_Table changed. See CHECK_STRUCTS comment in
>       config.h."
> # error "Lisp_Hash_Table changed. See CHECK_STRUCTS comment in config.h."
>   ^
> 1 error generated.
> make[1]: *** [pdumper.o] Error 1
> make: *** [src] Error 2

Fixed.

bug#36929: 27.0.50; Build on master broken

[Philipp Stephani]

Am Mo., 5. Aug. 2019 um 18:12 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> Philipp skrev:
>
> > I guess this is due to commit c74da403aa95ec67598c41aa4f1b97975391135b.
>
> If that change it is to blame, it was fixed later on; I can bootstrap 6c1d0d53b3 on macOS and Linux.
> Can you confirm?

Yes, this is definitely happening for me at commit 6c1d0d53b3, but no
longer at commit 81b34c45c6e9a8e9ad344dc498a111273adc388e (Eli's fix).
Did you run configure with --enable-checking=all
--enable-check-lisp-object-type?

bug#36929: 27.0.50; Build on master broken

[Mattias Engdegård]

5 aug. 2019 kl. 19.05 skrev Philipp Stephani <p.stephani2@gmail.com>:
> 
> Yes, this is definitely happening for me at commit 6c1d0d53b3, but no
> longer at commit 81b34c45c6e9a8e9ad344dc498a111273adc388e (Eli's fix).
> Did you run configure with --enable-checking=all
> --enable-check-lisp-object-type?

Thought I did, but was evidently mistaken. (Thanks for fixing it, Eli!)

bug#36929: 27.0.50; Build on master broken

[Paul Eggert]

> Should we maybe define CHECK_STRUCTS unconditionally to prevent issues
> like this?

Let's not, because CHECK_STRUCTS is more trouble than it's worth when doing 
serious development. See commit 9994bf17cf532f2e1d4310341da7180342202191 and 
related discussion.

If you run into this problem again, feel free to do what Eli did and commit a 
change to the hash to get your --enable-checking=structs build to work again. I 
don't bother because --enable-checking=structs is a waste of time for me, and I 
recommend against it.

bug#36929: 27.0.50; Build on master broken

[Andy Moreton]

On Mon 05 Aug 2019, Paul Eggert wrote:

>> Should we maybe define CHECK_STRUCTS unconditionally to prevent issues
>> like this?
>
> Let's not, because CHECK_STRUCTS is more trouble than it's worth when doing
> serious development. See commit 9994bf17cf532f2e1d4310341da7180342202191 and
> related discussion.
>
> If you run into this problem again, feel free to do what Eli did and commit a
> change to the hash to get your --enable-checking=structs build to work again.
> I don't bother because --enable-checking=structs is a waste of time for me,
> and I recommend against it.

It is reasonable to decide that CHECK_STRUCT is not useful for you
personally. It is not reasonable to introduce patches with known
breakage or to encourage others to do so.

Either this feature is useful and all developers must keep it up to date
when making changes, or it is not useful and should be removed.

    AndyM