bug#36225: 26.2.90; Can't build master

bug#36225: 26.2.90; Can't build master

[Philipp]

My repository is at commit 4058102c7cf3b96bb125473e407877c6dd7dfd61, but
I can't build:

$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
make[1]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib-src all
make[1]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all
  CC       pdumper.o
pdumper.c:2309:3: error: "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
# error "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
  ^
1 error generated.
make[1]: *** [pdumper.o] Error 1
make: *** [src] Error 2

$ ./config.status --config
'--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'


In GNU Emacs 26.2.90 (build 1, x86_64-apple-darwin18.6.0, NS appkit-1671.50 Version 10.14.5 (Build 18F132))
 of 2019-06-15
Repository revision: 200f63cfa5904462cdcb440d4da63dfa92c666a6
Windowing system distributor 'Apple', version 10.3.1671
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Eager macro-expansion failure: (error "Unknown seq pattern: (seq 3 (pred (lambda (c) (and (characterp c) (= (aref (symbol-name (category c)) 0) 76)))))")

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only
 MAKEINFO=/usr/local/opt/texinfo/bin/makeinfo CFLAGS=-O3'

Configured features:
JPEG NOTIFY ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS LCMS2

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 puny seq dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec epa epg
epg-config gnus-util rmail rmail-loaddefs 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
byte-opt bytecomp byte-compile cconv eieio-core cl-macs gv
eieio-loaddefs password-cache url-vars subr-x rx gnutls dbus xml
cl-loaddefs cl-lib elec-pair time-date 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 217790 8144)
 (symbols 48 21883 1)
 (miscs 40 49 173)
 (strings 32 33452 1237)
 (string-bytes 1 913190)
 (vectors 16 37190)
 (vector-slots 8 751578 19304)
 (floats 8 53 63)
 (intervals 56 202 0)
 (buffers 992 11))

bug#36225: 26.2.90; Can't build master

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> My repository is at commit 4058102c7cf3b96bb125473e407877c6dd7dfd61, but
> I can't build:
>
> $ make

Does "make bootstrap" help?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#36225: 26.2.90; Can't build master

[Eli Zaretskii]

> From: Philipp <p.stephani2@gmail.com>
> Date: Sat, 15 Jun 2019 17:39:10 +0200
> 
> 
> My repository is at commit 4058102c7cf3b96bb125473e407877c6dd7dfd61, but
> I can't build:
> 
> $ make
> /Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
> make[1]: Nothing to be done for `all'.
> /Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib-src all
> make[1]: Nothing to be done for `all'.
> /Applications/Xcode.app/Contents/Developer/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all
>   CC       pdumper.o
> pdumper.c:2309:3: error: "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
> # error "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
>   ^

The comment to CHECK_STRUCTS in src/config.h tells you what to do in
this case.

bug#36225: 26.2.90; Can't build master

[Philipp Stephani]

Am Sa., 15. Juni 2019 um 18:03 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Philipp <p.stephani2@gmail.com> writes:
>
> > My repository is at commit 4058102c7cf3b96bb125473e407877c6dd7dfd61, but
> > I can't build:
> >
> > $ make
>
> Does "make bootstrap" help?

Unfortunately not.

bug#36225: 26.2.90; Can't build master

[Philipp Stephani]

Am Sa., 15. Juni 2019 um 18:22 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp <p.stephani2@gmail.com>
> > Date: Sat, 15 Jun 2019 17:39:10 +0200
> >
> >
> > My repository is at commit 4058102c7cf3b96bb125473e407877c6dd7dfd61, but
> > I can't build:
> >
> > $ make
> > /Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
> > make[1]: Nothing to be done for `all'.
> > /Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib-src all
> > make[1]: Nothing to be done for `all'.
> > /Applications/Xcode.app/Contents/Developer/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all
> >   CC       pdumper.o
> > pdumper.c:2309:3: error: "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
> > # error "Lisp_Buffer_Objfwd changed. See CHECK_STRUCTS comment."
> >   ^
>
> The comment to CHECK_STRUCTS in src/config.h tells you what to do in
> this case.

Yes, it says "If you change one of these structures, check that the
pdumper.c code is still valid", but since I didn't change the
structure, I can't decide whether the pdumper code is still valid.
Whoever changed the definition of Lisp_Buffer_Objfwd should make that
call.

bug#36225: 26.2.90; Can't build master

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 15 Jun 2019 18:34:32 +0200
> Cc: 36225@debbugs.gnu.org
> 
> > The comment to CHECK_STRUCTS in src/config.h tells you what to do in
> > this case.
> 
> Yes, it says "If you change one of these structures, check that the
> pdumper.c code is still valid", but since I didn't change the
> structure, I can't decide whether the pdumper code is still valid.
> Whoever changed the definition of Lisp_Buffer_Objfwd should make that
> call.

It says to update the pertinent hash in pdumper.c by manually copying
the hash from dmpstruct.h.  The hash to be updated is called out by
the error message.  So I think the information you need is there to
fix your build.

bug#36225: 26.2.90; Can't build master

[Philipp Stephani]

Am Sa., 15. Juni 2019 um 18:51 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 15 Jun 2019 18:34:32 +0200
> > Cc: 36225@debbugs.gnu.org
> >
> > > The comment to CHECK_STRUCTS in src/config.h tells you what to do in
> > > this case.
> >
> > Yes, it says "If you change one of these structures, check that the
> > pdumper.c code is still valid", but since I didn't change the
> > structure, I can't decide whether the pdumper code is still valid.
> > Whoever changed the definition of Lisp_Buffer_Objfwd should make that
> > call.
>
> It says to update the pertinent hash in pdumper.c by manually copying
> the hash from dmpstruct.h.  The hash to be updated is called out by
> the error message.  So I think the information you need is there to
> fix your build.

That is not what I mean. Of course that fixes the build, that's not
the problem. But it would be incorrect and unsafe to blindly copy the
hash without investigating whether there were any changes to
Lisp_Buffer_Objfwd that would need to be reflected in pdumper.c.
That's the whole point of the hash check: force people to adapt
pdumper.c upon any struct change. That is what "If you change one of
these structures, check that the pdumper.c code is still valid" means:
whoever changed Lisp_Buffer_Objfwd (i.e., *not* me) needs to update
pdumper.c.

bug#36225: 26.2.90; Can't build master

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 15 Jun 2019 18:57:34 +0200
> Cc: 36225@debbugs.gnu.org
> 
> > It says to update the pertinent hash in pdumper.c by manually copying
> > the hash from dmpstruct.h.  The hash to be updated is called out by
> > the error message.  So I think the information you need is there to
> > fix your build.
> 
> That is not what I mean. Of course that fixes the build, that's not
> the problem. But it would be incorrect and unsafe to blindly copy the
> hash without investigating whether there were any changes to
> Lisp_Buffer_Objfwd that would need to be reflected in pdumper.c.
> That's the whole point of the hash check: force people to adapt
> pdumper.c upon any struct change. That is what "If you change one of
> these structures, check that the pdumper.c code is still valid" means:
> whoever changed Lisp_Buffer_Objfwd (i.e., *not* me) needs to update
> pdumper.c.

If real changes were needed in pdumper.c which were omitted, it is
unlikely that the problem persisted for more than a few hours.