Issue building master

Issue building master

[Ergus]

Hi:

I am trying to build the master branch and I am getting this error:

make[2]: Leaving directory '/mnt/almacen/repo/gits/emacs/build_arch/admin/charsets'
   CC       xdisp.o
   CC       gtkutil.o
   CC       coding.o
   CC       dbusbind.o
../../src/xdisp.c: In function ‘char_can_wrap_before’:
../../src/xdisp.c:541:8: error: ‘Vword_wrap_by_category’ undeclared (first use in this function)
   541 |   if (!Vword_wrap_by_category)
       |        ^~~~~~~~~~~~~~~~~~~~~~
../../src/xdisp.c:541:8: note: each undeclared identifier is reported only once for each function it appears in
../../src/xdisp.c: In function ‘char_can_wrap_after’:
../../src/xdisp.c:563:8: error: ‘Vword_wrap_by_category’ undeclared (first use in this function)
   563 |   if (!Vword_wrap_by_category)
       |        ^~~~~~~~~~~~~~~~~~~~~~
In file included from ../../src/xdisp.c:439:
../../src/xdisp.c: In function ‘syms_of_xdisp’:
../../src/lisp.h:3094:33: error: ‘struct emacs_globals’ has no member named ‘f_Vword_wrap_by_category’
  3094 |       = {Lisp_Fwd_Bool, &globals.f_##vname}; \
       |                                 ^
../../src/xdisp.c:34775:3: note: in expansion of macro ‘DEFVAR_BOOL’
34775 |   DEFVAR_BOOL("word-wrap-by-category", Vword_wrap_by_category, doc: /*
       |   ^~~~~~~~~~~
../../src/xdisp.c:34790:3: error: ‘Vword_wrap_by_category’ undeclared (first use in this function)
34790 |   Vword_wrap_by_category = false;
       |   ^~~~~~~~~~~~~~~~~~~~~~
   CC       keyboard.o
   CC       macros.o
make[1]: *** [Makefile:401: xdisp.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/mnt/almacen/repo/gits/emacs/build_arch/src'
make: *** [Makefile:424: src] Error 2

Re: Issue building master

[Eli Zaretskii]

> Date: Tue, 25 Aug 2020 02:19:01 +0200
> From: Ergus <spacibba@aol.com>
> 
> I am trying to build the master branch and I am getting this error:
> 
> make[2]: Leaving directory '/mnt/almacen/repo/gits/emacs/build_arch/admin/charsets'
>    CC       xdisp.o
>    CC       gtkutil.o
>    CC       coding.o
>    CC       dbusbind.o
> ../../src/xdisp.c: In function ‘char_can_wrap_before’:
> ../../src/xdisp.c:541:8: error: ‘Vword_wrap_by_category’ undeclared (first use in this function)
>    541 |   if (!Vword_wrap_by_category)
>        |        ^~~~~~~~~~~~~~~~~~~~~~
> ../../src/xdisp.c:541:8: note: each undeclared identifier is reported only once for each function it appears in

Something is wrong with regenerating globals.h (which should happen as
part of the build). I have no idea why this happens in your case.
Perhaps because you seem to be building outside of the source tree?
Or because there's a stale globals.h somewhere?  Try "make distclean"
first.

Re: Issue building master

[Ergus]

On Tue, Aug 25, 2020 at 09:17:17AM +0300, Eli Zaretskii wrote:
>> Date: Tue, 25 Aug 2020 02:19:01 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> I am trying to build the master branch and I am getting this error:
>>
>> make[2]: Leaving directory '/mnt/almacen/repo/gits/emacs/build_arch/admin/charsets'
>>    CC       xdisp.o
>>    CC       gtkutil.o
>>    CC       coding.o
>>    CC       dbusbind.o
>> ../../src/xdisp.c: In function ???char_can_wrap_before???:
>> ../../src/xdisp.c:541:8: error: ???Vword_wrap_by_category??? undeclared (first use in this function)
>>    541 |   if (!Vword_wrap_by_category)
>>        |        ^~~~~~~~~~~~~~~~~~~~~~
>> ../../src/xdisp.c:541:8: note: each undeclared identifier is reported only once for each function it appears in
>
>Something is wrong with regenerating globals.h (which should happen as
>part of the build). I have no idea why this happens in your case.
>Perhaps because you seem to be building outside of the source tree?
>Or because there's a stale globals.h somewhere?  Try "make distclean"
>first.
>
Hi Eli:

This solved the issue very thanks.

BTW when emacs was loading in: dump mode: nil mode

Many commands were failing here and there; one specially recurrent was
with an error in `load-history-filename-element` telling: wrong argument
type stringp (require 'something).

Is this "normal"?

Re: Issue building master

[Eli Zaretskii]

> Date: Tue, 25 Aug 2020 09:23:18 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> BTW when emacs was loading in: dump mode: nil mode
> 
> Many commands were failing here and there; one specially recurrent was
> with an error in `load-history-filename-element` telling: wrong argument
> type stringp (require 'something).
> 
> Is this "normal"?

What is "dump mode: nil mode"? where did you see this?

Re: Issue building master

[Ergus]

On Tue, Aug 25, 2020 at 10:28:52AM +0300, Eli Zaretskii wrote:
>> Date: Tue, 25 Aug 2020 09:23:18 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> BTW when emacs was loading in: dump mode: nil mode
>>
>> Many commands were failing here and there; one specially recurrent was
>> with an error in `load-history-filename-element` telling: wrong argument
>> type stringp (require 'something).
>>
>> Is this "normal"?
>
>What is "dump mode: nil mode"? where did you see this?
>
I already had this issue some time ago but yesterday it came back
again.

This message appear in the top of the Messages buffer when emacs can't
find the dump file (usually after a compilation issue like this if I
make bootstrap but not distclean). Then emacs loads all the packages
after that message which takes some time.

Stefan reported a similar issue about the problem of finding the
dump. And of course we shouldn't be using that mode but I won't expect
an error like that in load-history-filename-element.

Best,

Re: Issue building master

[Eli Zaretskii]

> Date: Tue, 25 Aug 2020 19:58:03 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> >> Is this "normal"?
> >
> >What is "dump mode: nil mode"? where did you see this?
> >
> I already had this issue some time ago but yesterday it came back
> again.
> 
> This message appear in the top of the Messages buffer when emacs can't
> find the dump file (usually after a compilation issue like this if I
> make bootstrap but not distclean). Then emacs loads all the packages
> after that message which takes some time.

This shouldn't happen, so perhaps there's a bug in one of the clean
targets in the Makefile: I guess it deletes the .pdmp file, but leaves
the executable.

Re: Issue building master

[Stefan Monnier]

> 34775 |   DEFVAR_BOOL("word-wrap-by-category", Vword_wrap_by_category, doc: /*

BTW, our convention is to use V<foo> for Lisp_Object variables exposed
to Lisp, not for bool variables exposed to Lisp, so the name should
likely lose the `V`.


        Stefan

Issue building master

[Ergus]

Hi:

I am building master today and I get this error:

```
make[2]: Entering directory '/mnt/almacen/repo/gits/emacs/build_arch/doc/misc'
   GEN      ../../../doc/misc/modus-themes.texi
File ‘../../../doc/misc/modus-themes.org’ not readable
make[2]: *** [Makefile:245: ../../../doc/misc/modus-themes.texi] Error 1
```

I already rebuilt the bootstrap and the usual fixes; but that didn't
solve the issue.

Any idea? 

Best,
Ergus

Re: Issue building master

[Michael Heerdegen]

Ergus <spacibba@aol.com> writes:

> Hi:
>
> I am building master today and I get this error:
>
> ```
> make[2]: Entering directory
> '/mnt/almacen/repo/gits/emacs/build_arch/doc/misc'
>   GEN      ../../../doc/misc/modus-themes.texi
> File ‘../../../doc/misc/modus-themes.org’ not readable
> make[2]: *** [Makefile:245: ../../../doc/misc/modus-themes.texi] Error 1
> ```

Worked for me some minutes ago.  There have been changes to the Makefile
only minutes and hours ago.  Maybe it is fixed meanwhile?

Michael.

Re: Issue building master

[Ergus]

On Sat, Feb 27, 2021 at 11:18:09PM +0100, Michael Heerdegen wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Hi:
>>
>> I am building master today and I get this error:
>>
>> ```
>> make[2]: Entering directory
>> '/mnt/almacen/repo/gits/emacs/build_arch/doc/misc'
>>   GEN      ../../../doc/misc/modus-themes.texi
>> File ‘../../../doc/misc/modus-themes.org’ not readable
>> make[2]: *** [Makefile:245: ../../../doc/misc/modus-themes.texi] Error 1
>> ```
>
>Worked for me some minutes ago.  There have been changes to the Makefile
>only minutes and hours ago.  Maybe it is fixed meanwhile?
>
>Michael.
>
Yes seems to be fixed now. Thanks

`cl-macs' [was: about keysee]

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

> >> For that, you can just use `M-x load-library' to load
> >> `cl-macs.el' and `M-x load-file to load `sortie.el'
> >> and then `keysee.el'.
> 
> You should never need to load/require explicitly `cl-macs`.
> Instead you should load/require `cl-lib` (which will then load cl-macs
> and other parts of cl-lib as/when needed).
> If you need to manually load `cl-macs` there's probably a bug somewhere.

`cl-macs' is autoloaded by `cl-lib'/`cl-loaddefs'.
So you don't need to load it explicitly if you
instead load `cl-lib'.  Of course.

But there's no need to load `cl-lib' or `cl', if
all you want is a macro from `cl-macs'.  Keysee
uses just 2 macros, nothing else from `cl*', and
both are in `cl-macs'.

Occam says "Just pull in what you really need."

(Same thing applies to a function definition,
but macros are often needed only when compiling,
in which case requiring them only at compile
time doesn't add libraries to your session.)

It's not about _needing_ to load `cl-macs'.  It's
about needing _only_ `cl-macs', and _not_ all of
`cl-lib'.  (And for older Emacs, not all of `cl'.)

If you just need a macro then you just need to
load the file that defines it (unless the macro 
definition needs some other file, of course).

Or to use your language, "You should never need to
load/require explicitly" cl-lib if all you need is
available from just cl-macs.  No?

Why should using `keysee' require you to also add
`cl-lib' to your session?  That's overreach.  I'd
sooner code without using something as simple as
`cl-case' than oblige someone to load `cl-lib'
just because I've used `cl-case'.

[And yes, things like `case' should just be part
of Emacs (just as `push' is).  And yes, `pcase'
is overkill for the simple variable-value case.]

[Plus, things have changed in `cl*' world over the
years.  What's there, and where, for older Emacs
can differ from what's there, and where, for more
recent releases.  Libraries that are usable with
multiple releases don't necessarily follow a "do
this" injunction that makes sense only for some
later releases.]

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13677 bytes --]

Re: `cl-macs' [was: about keysee]

[Stefan Monnier]

> Why should using `keysee' require you to also add
> `cl-lib' to your session?  That's overreach.  I'd

Requiring `cl-macs` won't help you there, because the first thing
`cl-macs` does is (require 'cl-lib).  Instead you want

    (eval-when-compile (require 'cl-lib))

> [Plus, things have changed in `cl*' world over the
> years.  What's there, and where, for older Emacs
> can differ from what's there, and where, for more
> recent releases.  Libraries that are usable with
> multiple releases don't necessarily follow a "do
> this" injunction that makes sense only for some
> later releases.]

That's exactly why you should require `cl-lib` rather than `cl-macs`:
because things can move between the different files of `cl-lib`.


        Stefan

RE: [External] : Re: `cl-macs' [was: about keysee]

[Drew Adams]

> Requiring `cl-macs` won't help you there, because the 
> first thing `cl-macs` does is (require 'cl-lib).

Ah, darn, so it does; too bad.  But thanks.

> Instead you want (eval-when-compile (require 'cl-lib))

Normally I do use eval-when-compile, in particular for
a macros file.  I don't recall why I didn't do it here,
for `cl-macs'.

Anyway it turns out that's insufficient, because  I also
use `cl-remove-if', which is in `cl-seq'.  Just picking
up `cl-lib' at compile time leaves that undefined.
(No doubt loading `cl-macs' at runtime took care of
`cl-remove-if' because it was loading `cl-lib', though I
likely wasn't aware of that.)

And `cl-seq' also requires `cl-lib'.  So I might as well
just require `cl-lib' at runtime.  That has the same
effect as what I've been doing all along (requiring
`cl-macs').  Anyway, I've made that change now.

Too bad - looks like there's no easy way to load just
the parts of `cl*' that are actually needed - separation
into different files provides no such benefit apparently. 

> > [Plus, things have changed in `cl*' world over the
> > years.  What's there, and where, for older Emacs
> > can differ from what's there, and where, for more
> > recent releases.  Libraries that are usable with
> > multiple releases don't necessarily follow a "do
> > this" injunction that makes sense only for some
> > later releases.]
> 
> That's exactly why you should require `cl-lib` rather than `cl-macs`:
> because things can move between the different files of `cl-lib`.

It's not just about changes within the `cl-lib' circus.
Some of my libraries are compatible back to earlier
releases that predate `cl-lib' (added in Emacs 23).
And `cl-macs' does still contain the macros.

Issue building master

[Ergus via Users list for the GNU Emacs text editor]

 Hi:
I just build master and I am getting this error in -nw:

Symbol's function definition is void: internal-echo-keystrokes-prefix

and this in gui:

Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes /home/ergo/.local/share/emacs/30.0.50/lisp/language /home/ergo/.local/share/emacs/30.0.50/lisp/international /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function definition is void: file-name-sans-extension
I tried the ussual: make extraclean, make bootstrap and the issue persists... Any other advise??
Thanks in advance, Ergus

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> branch: emacs-29
> commit b8d2ec920f37f5d77d32440eefc97dd5e8c2c7dc
> Author: Gregory Heytings <gregory@heytings.org>
> Commit: Gregory Heytings <gregory@heytings.org>
>
>     Revert "Improve last change to xfaces.c" (05ece1eb8b)
>     
>     * src/xfaces.c: Revert 05ece1eb8b.
>     
>     See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.

Don't do that!  You did not answer ANY part of what I said.

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> branch: emacs-29
>> commit b8d2ec920f37f5d77d32440eefc97dd5e8c2c7dc
>> Author: Gregory Heytings <gregory@heytings.org>
>> Commit: Gregory Heytings <gregory@heytings.org>
>>
>>     Revert "Improve last change to xfaces.c" (05ece1eb8b)
>>     
>>     * src/xfaces.c: Revert 05ece1eb8b.
>>     
>>     See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331.
>
> Don't do that!  You did not answer ANY part of what I said.

Btw, for posterity's sake, I undid this revert for two reasons:

  - unsetting the "extra" attribute is not safe on the Haiku port.
  - the bitmask variable is a real nusiance for anyone trying to
    debug Emacs or change the layout of the font attribute index
    enumerator.

Just because a bug has been closed does NOT mean the change in it is no
longer subject to scrutiny.  I don't follow bug reports that aren't
related to X, which means I (and possibly many others) only see changes
as they arrive on emacs-diffs.  Which means that by the time the bug is
closed, no, the discussion is not ``over'', and other people still have
a chance to make changes to problems they see as they see them (a
bitmask depending on the internal layout of an enum exposed to Lisp is
definitely one such problem, so is unsetting `:extra'.)

Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)

[Gregory Heytings]

>> Don't do that!  You did not answer ANY part of what I said.

Of course I did.  That you did not read it is another thing.

>
> Btw, for posterity's sake, I undid this revert for two reasons:
>

What kind of development practice is this?  You "improve" code in a 
complex area of the Emacs code base that was agreed upon after a long 
discussion only a couple of hours after it was pushed, without asking 
anyone whether what you want to do is okay?  And you revert without even 
reading or replying to the detailed explanation why that "improvement" was 
wrong.

>
> - unsetting the "extra" attribute is not safe on the Haiku port.
>

That's wrong.  And you would have understood this if you had read the 
detailed explanation why your "improvement" is wrong.

>
> - the bitmask variable is a real nusiance for anyone trying to debug 
> Emacs or change the layout of the font attribute index enumerator.
>

It isn't, and it is not supposed to be modified on a daily basis.

>
> Just because a bug has been closed does NOT mean the change in it is no 
> longer subject to scrutiny. I don't follow bug reports that aren't 
> related to X, which means I (and possibly many others) only see changes 
> as they arrive on emacs-diffs.  Which means that by the time the bug is 
> closed, no, the discussion is not ``over'', and other people still have 
> a chance to make changes to problems they see as they see them (a 
> bitmask depending on the internal layout of an enum exposed to Lisp is 
> definitely one such problem, so is unsetting `:extra'.)
>

Nobody said the discussion was over (although I was hoping it was).

But what you did is not a "discussion", it is the exact opposite of a 
"discussion": these are misguided changes introduced in the release branch 
_without any discussion_.

Issue building master

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

 Hi:
I sent this to emacs help with no reply, so maybe here I'll get more luck:

I just built the master branch and I am getting this error with -nw:

```
Symbol's function definition is void: internal-echo-keystrokes-prefix
```

and this in gui:

```
Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes /home/ergo/.local/share/emacs/30.0.50/lisp/language /home/ergo/.local/share/emacs/30.0.50/lisp/international /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function definition is void: file-name-sans-extension
``
I tried the usual: make extraclean, make bootstrap and the issue persists... Any other advise??

Thanks in advance, Ergus


[-- Attachment #2: Type: text/html, Size: 1832 bytes --]

Re: Issue building master

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 09:37:05 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> I just built the master branch and I am getting this error with -nw:
> 
> ```
> Symbol's function definition is void: internal-echo-keystrokes-prefix
> ```

Is this when building or when starting after the build completes?  (I
see no problem in either case.)

> and this in gui:
> 
> ```
> Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp
> /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp
> /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes /home/ergo/.local/share/emacs/30.0.50/lisp/language
> /home/ergo/.local/share/emacs/30.0.50/lisp/international
> /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes
> /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function definition
> is void: file-name-sans-extension
> ``

If this is during startup after the build, then your pdmp file either
doesn't exist or is faulty.

If this is during a build, then why does it say "Dump mode: nil"?

What happens if you clone the repository anew, and then do a fresh
build?

Re: Issue building master

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 13:56:58 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> Is this when building or when starting after the build completes?  (I
> see no problem in either case.)
> 
> When starting after the build completes.
> 
> > and this in gui:
> > 
> > ```
> > Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes
> /home/ergo/.local/share/emacs/30.0.50/lisp/language
> > /home/ergo/.local/share/emacs/30.0.50/lisp/international
> > /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes
> > /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function
> definition
> > is void: file-name-sans-extension
> > ``
> 
> If this is during startup after the build, then your pdmp file either
> doesn't exist or is faulty.
> 
> This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> this?

Do you install Emacs (as in "make install"), or do you run it from the
source tree?

P.S. And please don't remove the list from the CC.

Re: Issue building master

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

 

    On Monday, December 12, 2022 at 03:15:46 PM GMT+1, Eli Zaretskii <eliz@gnu.org> wrote:  
 
 > Date: Mon, 12 Dec 2022 13:56:58 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> 
> Is this when building or when starting after the build completes?  (I
> see no problem in either case.)
> 
> When starting after the build completes.
> 
> > and this in gui:
> > 
> > ```
> > Loading loadup.el (source)...Dump mode: nilUsing load-path (/home/ergo/.local/share/emacs/30.0.50/lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/emacs-lisp
> > /home/ergo/.local/share/emacs/30.0.50/lisp/progmodes
> /home/ergo/.local/share/emacs/30.0.50/lisp/language
> > /home/ergo/.local/share/emacs/30.0.50/lisp/international
> > /home/ergo/.local/share/emacs/30.0.50/lisp/textmodes
> > /home/ergo/.local/share/emacs/30.0.50/lisp/vc)Loading emacs-lisp/debug-early...Symbol's function
> definition
> > is void: file-name-sans-extension
> > ``
> 
> If this is during startup after the build, then your pdmp file either
> doesn't exist or is faulty.
> 
> This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> this?

Do you install Emacs (as in "make install"), or do you run it from the
source tree?

From source tree. I checkout to other branches, old commits, recompiled, emacs -Q... just same error again and again. 



P.S. And please don't remove the list from the CC.
Sorry I am using a weird web client (as emacs is broken) I am not sure how does it work

  

[-- Attachment #2: Type: text/html, Size: 3117 bytes --]

Re: Issue building master

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 15:49:29 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > If this is during startup after the build, then your pdmp file either
> > doesn't exist or is faulty.
> > 
> > This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> > this?
> 
> Do you install Emacs (as in "make install"), or do you run it from the
> source tree?
> 
> From source tree. I checkout to other branches, old commits, recompiled, emacs -Q... just same
> error again and again. 

The emacs-29 branch also?  And a clean new clone also?  Then it's
almost certainly something specific to your system.  Did you update
some libraries or tools or some other software lately?

What if you try configuring Emacs with

  ./configure ... --enable-checking='yes,glyphs' CFLAGS='-O0 -g3'

(where "..." stands for the other options you use when you configure
Emacs) -- do you see something different?

If you download the Emacs 28.2 tarball, can you build and run it?

Re: Issue building master

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

 Hi:
    On Monday, December 12, 2022 at 05:05:12 PM GMT+1, Eli Zaretskii <eliz@gnu.org> wrote:  
 
 > Date: Mon, 12 Dec 2022 15:49:29 +0000 (UTC)
> From: Ergus <spacibba@aol.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > If this is during startup after the build, then your pdmp file either
> > doesn't exist or is faulty.
> > 
> > This looks like the issue... How can I solve this? Make extracleanor make boostrap does not solve
> > this?
> 
> Do you install Emacs (as in "make install"), or do you run it from the
> source tree?
> 
> From source tree. I checkout to other branches, old commits, recompiled, emacs -Q... just same
> error again and again. 

The emacs-29 branch also? Yes.
And a clean new clone also?  Then it's almost certainly something specific to your system.  Did you updatesome libraries or tools or some other software lately?actually I use Arch, so yes because it is a rolling release. But I don't have any other problem with anything else, just emacs.. so... not sure it is my system...
What if you try configuring Emacs with

  ./configure ... --enable-checking='yes,glyphs' CFLAGS='-O0 -g3'

(where "..." stands for the other options you use when you configure
Emacs) -- do you see something different?
Same behavior
If you download the Emacs 28.2 tarball, can you build and run it?
I will try this one in a while then...

Sorry for too much bother, but this is making me crazy since yesterday...
  

[-- Attachment #2: Type: text/html, Size: 3348 bytes --]