GNU bug report logs -
#45303
28.0.50; [feature/native-comp] comp.c compilation error on Windows 10
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45303 in the body.
You can then email your comments to 45303 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 20:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Liāu, Kiong-Gē 廖宮毅 <gongyi.liao <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 17 Dec 2020 20:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I tried to build feature/native-comp branch on Windows 10 using the most
up-to-date Msys2 system's mingw-w64-x86_64-gcc and mingw-w64-x86_64-libgccjit
as 2020-12-16.
The build is configured with flag
'configure --prefix=/home/VWinUser0/Downloads/emacs/native-comp
--with-nativecomp'
Configured for 'x86_64-w64-mingw32'.
Where should the build process find the source code? ../src
What compiler should emacs be built with? gcc -g3 -O2 -gdwarf-2
Should Emacs use the GNU version of malloc? no
(The GNU allocators don't work with this system configuration.)
Should Emacs use a relocating allocator for buffers? no
Should Emacs use mmap(2) for buffer allocation? yes
What window system should Emacs use? w32
What toolkit should Emacs use? none
Where do we find X Windows header files? NONE
Where do we find X Windows libraries? NONE
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? yes
Does Emacs use -ljpeg? yes
Does Emacs use -ltiff? yes
Does Emacs use a gif library? yes
Does Emacs use a png library? yes
Does Emacs use -lrsvg-2? yes
Does Emacs use cairo? no
Does Emacs use -llcms2? yes
Does Emacs use imagemagick? no
Does Emacs use native APIs for images? yes (w32)
Does Emacs support sound? yes
Does Emacs use -lgpm? no
Does Emacs use -ldbus? no
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
Does Emacs use a file notification library? yes (w32)
Does Emacs use access control lists? yes
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? yes
Does Emacs use -lxml2? yes
Does Emacs use -lfreetype? no
Does Emacs use HarfBuzz? yes
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? no
Does Emacs use -lsystemd? no
Does Emacs use -ljansson? yes
Does Emacs use the GMP library? yes
Does Emacs directly use zlib? yes
Does Emacs have dynamic modules support? yes
Does Emacs use toolkit scroll bars? yes
Does Emacs support Xwidgets? no
Does Emacs have threading support in lisp? yes
Does Emacs support the portable dumper? yes
Does Emacs support legacy unexec dumping? no
Which dumping strategy does Emacs use? pdumper
Does Emacs have native lisp compiler? yes
configure: creating ./config.status
config.status: creating nt/emacs.rc
config.status: creating nt/emacsclient.rc
config.status: creating src/emacs-module.h
config.status: creating Makefile
config.status: creating lib/gnulib.mk
config.status: creating ../src/doc/man/emacs.1
config.status: creating lib/Makefile
config.status: creating lib-src/Makefile
config.status: creating oldXMenu/Makefile
config.status: creating doc/emacs/Makefile
config.status: creating doc/misc/Makefile
config.status: creating doc/lispintro/Makefile
config.status: creating doc/lispref/Makefile
config.status: creating src/Makefile
The compilation kicked-off using `make`, and it stopped at comp.c
with the following error message:
CC comp.o
../../src/src/comp.c: In function 'Fcomp_el_to_eln_filename':
../../src/src/comp.c:4110:36: error: expected ')' before 'PATH_REL_LOADSEARCH'
4110 | Fregexp_quote (build_string ("/" PATH_REL_LOADSEARCH "/")));
| ^~~~~~~~~~~~~~~~~~~~
| )
../../src/src/comp.c: In function 'Fcomp__compile_ctxt_to_file':
../../src/src/comp.c:4458:12: warning: unused variable 'oldset'
[-Wunused-variable]
4458 | sigset_t oldset;
| ^~~~~~
../../src/src/comp.c: In function 'eln_load_path_final_clean_up':
../../src/src/comp.c:4621:29: warning: passing argument 1 of
'internal_condition_case_4' from incompatible pointer type
[-Wincompatible-pointer-types]
4621 | internal_condition_case_4 (Fdirectory_files,
| ^~~~~~~~~~~~~~~~
| |
| struct Lisp_X * (*)(struct Lisp_X
*, struct Lisp_X *, struct Lisp_X *, struct Lisp_X *, struct Lisp_X *)
In file included from ../../src/src/comp.c:23:
../../src/src/lisp.h:4160:47: note: expected 'struct Lisp_X *
(*)(struct Lisp_X *, struct Lisp_X *, struct Lisp_X *, struct Lisp_X
*)' but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *,
struct Lisp_X *, struct Lisp_X *, struct Lisp_X *, struct Lisp_X *)'
4160 | extern Lisp_Object internal_condition_case_4 (Lisp_Object (*)
(Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object), Lisp_Object,
Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*)
(Lisp_Object));
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile:410: comp.o] Error 1
make[1]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/src'
make: *** [Makefile:433: src] Error 2
src/epaths.h has the following content:
$ cat src/epaths.h
/* Hey Emacs, this is -*- C -*- code! */
/* epaths.in file for MS-Windows build that uses the configure script.
Since Emacs on Windows must be relocatable to any directory, it
cannot have here hard-coded directories determined at configure
time. Therefore, each directory must begin with %emacs_dir%, which
is resolved at startup to the root of the Emacs installation tree
(see w32.c:init_environment).
This file is edited at configure time to replace @VER@ by the Emacs
version being built (e.g., 25.9.77), @CFG@ by the canonical name of
the host system (e.g., i686-pc-mingw32), and @SRC@ by the root of
the Emacs source tree used to build Emacs. */
/*
Copyright (C) 1993, 1995, 1997, 1999, 2001-2020 Free Software
Foundation, Inc.
This file is part of GNU Emacs.
GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. */
/* Together with PATH_SITELOADSEARCH, this gives the default value of
load-path, which is the search path for the Lisp function "load".
Configure (using "make epaths-force") sets this to
${standardlisppath}, which typically has a value like:
<datadir>/emacs/VERSION/lisp where datadir is eg /usr/local/share.
*/
#define PATH_LOADSEARCH "%emacs_dir%/share/emacs/28.0.50/lisp"
/* Like PATH_LOADSEARCH, but contains the non-standard pieces.
These are the site-lisp directories. Configure sets this to
${locallisppath}, which typically defaults to something like:
<datadir>/emacs/VERSION/site-lisp:<datadir>/emacs/site-lisp
but can be overridden by the --enable-locallisppath argument.
This is combined with PATH_LOADSEARCH to make the default load-path.
If the --no-site-lisp option is used, this piece is excluded.
*/
#define PATH_SITELOADSEARCH
"%emacs_dir%/share/emacs/28.0.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
/* Like PATH_LOADSEARCH, but used only during the build process
when Emacs is dumping. Configure (using "make epaths-force-w32") sets
this to $buildlisppath, which normally has the value: <srcdir>/lisp.
*/
#define PATH_DUMPLOADSEARCH
"C:/msys64/home/VWinUser0/Downloads/emacs/native-comp/src/lisp"
/* The extra search path for programs to invoke. This is appended to
whatever the PATH environment variable says to set the Lisp
variable exec-path and the first file name in it sets the Lisp
variable exec-directory. exec-directory is used for finding
executables and other architecture-dependent files. */
#define PATH_EXEC "%emacs_dir%/libexec/emacs/28.0.50/x86_64-w64-mingw32"
/* Where Emacs should look for its architecture-independent data
files, like the NEWS file. The lisp variable data-directory
is set to this value. */
#define PATH_DATA "%emacs_dir%/share/emacs/28.0.50/etc"
/* Where Emacs should look for X bitmap files.
The lisp variable x-bitmap-file-path is set based on this value. */
#define PATH_BITMAPS ""
/* Where Emacs should look for its docstring file. The lisp variable
doc-directory is set to this value. */
#define PATH_DOC "%emacs_dir%/share/emacs/28.0.50/etc"
/* Where the configuration process believes the info tree lives. The
lisp variable configure-info-directory gets its value from this
macro, and is then used to set the Info-default-directory-list. */
#define PATH_INFO "%emacs_dir%/share/info"
/* Where Emacs should store game score files. */
#define PATH_GAME "%emacs_dir%/var/games/emacs"
/* Where Emacs should look for the application default file. */
#define PATH_X_DEFAULTS ""
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 20:32:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Hi,
could you share also the config.log?
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 20:34:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Hi,
could you share also the config.log?
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 20:42:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
the attached file is the config.log file
On Thu, Dec 17, 2020 at 2:33 PM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Hi,
>
> could you share also the config.log?
>
> Thanks!
>
> Andrea
[config.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 20:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 45303 <at> debbugs.gnu.org (full text, mbox):
"Liāu, Kiong-Gē 廖宮毅" <gongyi.liao <at> gmail.com> writes:
> the attached file is the config.log file
I've pushed 174f2a92eb, could you please have a try? I've no windows machine on
to test it myself.
Thanks!
Andrea
PS which version of GCC are you on?
PPS could you post the full log of the compilation next time? You get
warnings I'dont get but the output is cutted.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 21:04:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 17 Dec 2020 20:57:29 +0000
> Cc: 45303 <at> debbugs.gnu.org
> From: Andrea Corallo via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> I've pushed 174f2a92eb, could you please have a try? I've no windows machine on
> to test it myself.
Don't you need to update also the epaths-force-w32 target in
Makefile.in?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 21:11:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 17 Dec 2020 20:57:29 +0000
>> Cc: 45303 <at> debbugs.gnu.org
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> I've pushed 174f2a92eb, could you please have a try? I've no windows machine on
>> to test it myself.
>
> Don't you need to update also the epaths-force-w32 target in
> Makefile.in?
Uops, pushed 87f6e93799 thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 21:28:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 45303 <at> debbugs.gnu.org (full text, mbox):
commit 87f6e93799 lead to successful compilation of comp.c, but lead
to linker errors while generating temacs.exe:
CCLD temacs.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
comp.o: in function `md5_gz_stream':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
undefined reference to `inflateInit2_'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
undefined reference to `inflate'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:741:
undefined reference to `inflateEnd'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:741:
undefined reference to `inflateEnd'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
comp.o: in function `declare_imported_func':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:973:
undefined reference to `gcc_jit_type_get_const'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
process.o: in function `status_message':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/process.c:754:
undefined reference to `strsignal'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
callproc.o: in function `call_process':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/callproc.c:916:
undefined reference to `strsignal'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:661: temacs.exe] Error 1
make[1]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/src'
make: *** [Makefile:434: src] Error 2
On Thu, Dec 17, 2020 at 3:10 PM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Thu, 17 Dec 2020 20:57:29 +0000
> >> Cc: 45303 <at> debbugs.gnu.org
> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> I've pushed 174f2a92eb, could you please have a try? I've no windows machine on
> >> to test it myself.
> >
> > Don't you need to update also the epaths-force-w32 target in
> > Makefile.in?
>
> Uops, pushed 87f6e93799 thanks
>
> Andrea
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Thu, 17 Dec 2020 21:42:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 45303 <at> debbugs.gnu.org (full text, mbox):
"Liāu, Kiong-Gē 廖宮毅" <gongyi.liao <at> gmail.com> writes:
> commit 87f6e93799 lead to successful compilation of comp.c, but lead
> to linker errors while generating temacs.exe:
>
>
> CCLD temacs.exe
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> comp.o: in function `md5_gz_stream':
> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
> undefined reference to `inflateInit2_'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
> undefined reference to `inflate'
That's curious, looks you've not zlib but from the config.log you do...
Closing the day and will think about that tomorrow, perhaps someone will
suggest what I'm missing in the meanwhile.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 13:29:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> "Liāu, Kiong-Gē 廖宮毅" <gongyi.liao <at> gmail.com> writes:
>
>> commit 87f6e93799 lead to successful compilation of comp.c, but lead
>> to linker errors while generating temacs.exe:
>>
>>
>> CCLD temacs.exe
>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> comp.o: in function `md5_gz_stream':
>> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
>> undefined reference to `inflateInit2_'
>> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
>> undefined reference to `inflate'
>
> That's curious, looks you've not zlib but from the config.log you do...
I really would like to understand what's going on here.
We check in configure for zlib presence, actually this is also require
by --with-nativecomp but somehow the linker fails to find it.
Is zlib installed in your system?
If yes could you post the full output of 'make V=1'?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 13:30:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 15:41:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 16:03:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Pal Gloss <pcfeb0009 <at> gmx.com> writes:
> Hi,
Hi Pal,
> Just in case this helps (sorry I did not have time to split up this into separate bug reports, but it will help [I hope]
> fix the problems encountered): here are the notes/hacks/command lines I used to build a recent gccemacs on my Win10
> machine with mingw64:
good to know is working even if with some hacking on it ;)
> #+begin_src shell :exports code
> git rev-parse HEAD feature/native-comp
> #+end_src
> : 682bd303470d4a0fcd2690aff6aa58fb720a8d41
> : 682bd303470d4a0fcd2690aff6aa58fb720a8d41
>
> #+begin_src shell :exports code
> pacman -S --needed base-devel \
> mingw-w64-x86_64-toolchain \
> mingw-w64-x86_64-xpm-nox \
> mingw-w64-x86_64-libtiff \
> mingw-w64-x86_64-giflib \
> mingw-w64-x86_64-libpng \
> mingw-w64-x86_64-libjpeg-turbo \
> mingw-w64-x86_64-librsvg \
> mingw-w64-x86_64-lcms2 \
> mingw-w64-x86_64-jansson \
> mingw-w64-x86_64-libxml2 \
> mingw-w64-x86_64-gnutls \
> mingw-w64-x86_64-zlib \
> mingw-w64-x86_64-harfbuzz \
> mingw-w64-x86_64-libgccjit
> PROCESSORS_TO_USE="3"
> EMACS_VERSION=emacs-native-comp
> ./autogen.sh
> # edit nt/epaths.nt to add PATH_REL_LOADSEARCH:
> grep -q PATH_REL_LOADSEARCH nt/epaths.nt || echo '#define PATH_REL_LOADSEARCH ""' >> nt/epaths.nt
This should be fixed by yesterday commits
> # patch to look for libgccjit-0.dll instead of libgcc.dll? lisp/term/w32-win.el & src/emacs.c
> sed -i -e 's/libgccjit.dll/libgccjit-0.dll/' lisp/term/w32-win.el
> sed -i -e 's/libgccjit.dll/libgccjit-0.dll/' src/emacs.c
I've really no windows knowledge to judge that, perhaps Eli will
comment. If these are correct fixes you should submit a patch for
those.
> # patch to avoid gcc_jit_global_set_initializer (crashes on my machine...; it
> # seems there is an interaction with the #pragma and the rest of the parsing
> # because the statement is incomplete?) and to adapt to (new) 5th parameter to
> # directory-files
> sed -i -e '/if (gcc_jit_global_set_initializer)/,/{/ {
> /#pragma GCC diagnostic pop/d
> /{/a #pragma GCC diagnostic pop
> }' \
> -e '/internal_condition_case_4/,/FOR_EACH/ {
> s/internal_condition_case_4/internal_condition_case_5/
> s/Qt, return_nil);/Qnil, Qt, return_nil);/
> }' \
> src/comp.c
which gcc version are you using?
> sed -i -e '/extern Lisp_Object internal_condition_case_4/a extern Lisp_Object internal_condition_case_5 (Lisp_Object
> (*) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));' src/lisp.h
> sed -i -e '/Like internal_condition_case_1 but call BFUN with ARG1, ARG2, ARG3, ARG4 as/ {
> s/ARG4 as/ARG4, ARG5 as/
> a its arguments. */
> a Lisp_Object
> a internal_condition_case_5 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object,
> a Lisp_Object, Lisp_Object,
> a Lisp_Object),
> a Lisp_Object arg1, Lisp_Object arg2,
> a Lisp_Object arg3, Lisp_Object arg4,
> a Lisp_Object arg5,
> a Lisp_Object handlers,
> a Lisp_Object (*hfun) (Lisp_Object))
> a {
> a struct handler *c = push_handler (handlers, CONDITION_CASE);
> a if (sys_setjmp (c->jmp))
> a {
> a Lisp_Object val = handlerlist->val;
> a clobbered_eassert (handlerlist == c);
> a handlerlist = handlerlist->next;
> a return hfun (val);
> a }
> a else
> a {
> a Lisp_Object val = bfun (arg1, arg2, arg3, arg4, arg5);
> a eassert (handlerlist == c);
> a handlerlist = c->next;
> a return val;
> a }
> a }
> a /* Like internal_condition_case_1 but call BFUN with ARG1, ARG2, ARG3, ARG4 as
> }' src/eval.c
> sed -i -e '/PATH_EXEC, 0);/ {
> s/.*/#ifdef WINDOWSNT/
> a /* On MS-Windows, PATH_EXEC normally starts with a literal
> a "%emacs_dir%", so it will never work without some tweaking. */
> a w32_relocate (PATH_EXEC),
> a #else
> a PATH_EXEC,
> a #endif
> a 0);
> }' src/callproc.c
> mkdir -p ../build
> cd ../build
> ../emacs/configure \
> --with-xml2 \
> --without-pop \
> --prefix="/home/cramaph1/$EMACS_VERSION/dest" \
> --without-compress-install \
> --without-dbus \
> --with-nativecomp \
> --with-modules 'CFLAGS=-O2 -g3' 'LIBGCCJIT=-lz -lgccjit'
> sed -i -e 's/^LIBGCCJIT = *$/LIBGCCJIT = -lz -lgccjit/' src/Makefile
> make -j"$PROCESSORS_TO_USE"
> make install
> #+end_src
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 16:08:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 18 Dec 2020 13:28:20 +0000
> Cc: gongyi.liao <at> gmail.com, =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> From: Andrea Corallo via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> >> CCLD temacs.exe
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> comp.o: in function `md5_gz_stream':
> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
> >> undefined reference to `inflateInit2_'
> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
> >> undefined reference to `inflate'
> >
> > That's curious, looks you've not zlib but from the config.log you do...
>
> I really would like to understand what's going on here.
>
> We check in configure for zlib presence, actually this is also require
> by --with-nativecomp but somehow the linker fails to find it.
Why does the native-comp branch require zlib in comp.c? what does it
do with zlib?
On master, zlib is an optional library, and when some Emacs command is
invoked that needs it, on MS-Windows we load the zlib DLL at run time
when requested. See init_zlib_functions in decompress.c. This is
unlike on Posix systems, where Emacs is linked with zlib at link time.
Does this explain what is going on?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 16:38:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Fri, 18 Dec 2020 13:28:20 +0000
>> Cc: gongyi.liao <at> gmail.com, =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> >> CCLD temacs.exe
>> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> >> comp.o: in function `md5_gz_stream':
>> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
>> >> undefined reference to `inflateInit2_'
>> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
>> >> undefined reference to `inflate'
>> >
>> > That's curious, looks you've not zlib but from the config.log you do...
>>
>> I really would like to understand what's going on here.
>>
>> We check in configure for zlib presence, actually this is also require
>> by --with-nativecomp but somehow the linker fails to find it.
>
> Why does the native-comp branch require zlib in comp.c? what does it
> do with zlib?
We hash the content of the lisp source files to obtain the correspondent
eln name in the eln-cache.
This machinery has to work since early bootstrap (and has to be fast
since is executed at each file load), so is directly done from comp.c.
When Emacs is installed the el files are compressed and so before
hashing them we have to decompress therefore we use zlib.
> On master, zlib is an optional library, and when some Emacs command is
> invoked that needs it, on MS-Windows we load the zlib DLL at run time
> when requested. See init_zlib_functions in decompress.c. This is
> unlike on Posix systems, where Emacs is linked with zlib at link time.
> Does this explain what is going on?
I see, we should probably have comp.c use the necessary DEF_DLL_FN bloat
or have these functions wrapped in decompress.c.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 19:36:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 45303 <at> debbugs.gnu.org (full text, mbox):
By changing src/Makefile's temacs target to:
temacs$(EXEEXT): $(LIBXMENU) $(ALLOBJS) $(LIBEGNU_ARCHIVE) $(EMACSRES) \
$(charsets) $(charscript) $(MAKE_PDUMPER_FINGERPRINT)
$(AM_V_CCLD)$(CC) -o $@.tmp \
$(ALL_CFLAGS) $(TEMACS_LDFLAGS) $(LDFLAGS) \
$(ALLOBJS) $(LIBEGNU_ARCHIVE) $(W32_RES_LINK) $(LIBES) \
-lgccjit -lz
Now the temacs is successfully generated, however, at ELC+ELN step of
macroexpand.el, temacs just crashed:
make[2]: Entering directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
ELC+ELN ../../src/lisp/emacs-lisp/macroexp.elc
Backtrace:
00000004001adbe2
00000004000b40a6
00000004000ccc64
000000040020581a
00007ffeba377ff0
00007ffebb9910f7
00007ffebb93b46c
00007ffebb98fc26
make[2]: *** [Makefile:319: ../../src/lisp/emacs-lisp/macroexp.elc] Error 255
make[2]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
make[1]: *** [Makefile:833: bootstrap-emacs.pdmp] Error 2
make[1]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/src'
make: *** [Makefile:434: src] Error 2
Such a problem does not occur on Linux or FreeBSD.
Thanks,
Kiong-Ge.
On Fri, Dec 18, 2020 at 10:37 AM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Fri, 18 Dec 2020 13:28:20 +0000
> >> Cc: gongyi.liao <at> gmail.com, =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> >> CCLD temacs.exe
> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> >> comp.o: in function `md5_gz_stream':
> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
> >> >> undefined reference to `inflateInit2_'
> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
> >> >> undefined reference to `inflate'
> >> >
> >> > That's curious, looks you've not zlib but from the config.log you do...
> >>
> >> I really would like to understand what's going on here.
> >>
> >> We check in configure for zlib presence, actually this is also require
> >> by --with-nativecomp but somehow the linker fails to find it.
> >
> > Why does the native-comp branch require zlib in comp.c? what does it
> > do with zlib?
>
> We hash the content of the lisp source files to obtain the correspondent
> eln name in the eln-cache.
>
> This machinery has to work since early bootstrap (and has to be fast
> since is executed at each file load), so is directly done from comp.c.
>
> When Emacs is installed the el files are compressed and so before
> hashing them we have to decompress therefore we use zlib.
>
> > On master, zlib is an optional library, and when some Emacs command is
> > invoked that needs it, on MS-Windows we load the zlib DLL at run time
> > when requested. See init_zlib_functions in decompress.c. This is
> > unlike on Posix systems, where Emacs is linked with zlib at link time.
> > Does this explain what is going on?
>
> I see, we should probably have comp.c use the necessary DEF_DLL_FN bloat
> or have these functions wrapped in decompress.c.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 19:41:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 45303 <at> debbugs.gnu.org (full text, mbox):
By changing src/Makefile's temacs target to:
temacs$(EXEEXT): $(LIBXMENU) $(ALLOBJS) $(LIBEGNU_ARCHIVE) $(EMACSRES) \
$(charsets) $(charscript) $(MAKE_PDUMPER_FINGERPRINT)
$(AM_V_CCLD)$(CC) -o $@.tmp \
$(ALL_CFLAGS) $(TEMACS_LDFLAGS) $(LDFLAGS) \
$(ALLOBJS) $(LIBEGNU_ARCHIVE) $(W32_RES_LINK) $(LIBES) \
-lgccjit -lz
Now the temacs is successfully generated, however, at ELC+ELN step of
macroexpand.el, temacs just crashed:
make[2]: Entering directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
ELC+ELN ../../src/lisp/emacs-lisp/macroexp.elc
Backtrace:
00000004001adbe2
00000004000b40a6
00000004000ccc64
000000040020581a
00007ffeba377ff0
00007ffebb9910f7
00007ffebb93b46c
00007ffebb98fc26
make[2]: *** [Makefile:319: ../../src/lisp/emacs-lisp/macroexp.elc] Error 255
make[2]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
make[1]: *** [Makefile:833: bootstrap-emacs.pdmp] Error 2
make[1]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/src'
make: *** [Makefile:434: src] Error 2
Such a problem does not occur on Linux or FreeBSD.
Thanks,
Kiong-Ge.
On Fri, Dec 18, 2020 at 10:37 AM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Fri, 18 Dec 2020 13:28:20 +0000
> >> Cc: gongyi.liao <at> gmail.com, =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> >> CCLD temacs.exe
> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> >> comp.o: in function `md5_gz_stream':
> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
> >> >> undefined reference to `inflateInit2_'
> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
> >> >> undefined reference to `inflate'
> >> >
> >> > That's curious, looks you've not zlib but from the config.log you do...
> >>
> >> I really would like to understand what's going on here.
> >>
> >> We check in configure for zlib presence, actually this is also require
> >> by --with-nativecomp but somehow the linker fails to find it.
> >
> > Why does the native-comp branch require zlib in comp.c? what does it
> > do with zlib?
>
> We hash the content of the lisp source files to obtain the correspondent
> eln name in the eln-cache.
>
> This machinery has to work since early bootstrap (and has to be fast
> since is executed at each file load), so is directly done from comp.c.
>
> When Emacs is installed the el files are compressed and so before
> hashing them we have to decompress therefore we use zlib.
>
> > On master, zlib is an optional library, and when some Emacs command is
> > invoked that needs it, on MS-Windows we load the zlib DLL at run time
> > when requested. See init_zlib_functions in decompress.c. This is
> > unlike on Posix systems, where Emacs is linked with zlib at link time.
> > Does this explain what is going on?
>
> I see, we should probably have comp.c use the necessary DEF_DLL_FN bloat
> or have these functions wrapped in decompress.c.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 20:50:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 45303 <at> debbugs.gnu.org, gongyi.liao <at> gmail.com,
> =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> Date: Fri, 18 Dec 2020 16:37:31 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Fri, 18 Dec 2020 13:28:20 +0000
> >> Cc: gongyi.liao <at> gmail.com, =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> >> CCLD temacs.exe
> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> >> comp.o: in function `md5_gz_stream':
> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
> >> >> undefined reference to `inflateInit2_'
> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
> >> >> undefined reference to `inflate'
> >> >
> >> > That's curious, looks you've not zlib but from the config.log you do...
> >>
> >> I really would like to understand what's going on here.
> >>
> >> We check in configure for zlib presence, actually this is also require
> >> by --with-nativecomp but somehow the linker fails to find it.
> >
> > Why does the native-comp branch require zlib in comp.c? what does it
> > do with zlib?
>
> We hash the content of the lisp source files to obtain the correspondent
> eln name in the eln-cache.
>
> This machinery has to work since early bootstrap (and has to be fast
> since is executed at each file load), so is directly done from comp.c.
>
> When Emacs is installed the el files are compressed and so before
> hashing them we have to decompress therefore we use zlib.
Thanks for the explanations.
> > On master, zlib is an optional library, and when some Emacs command is
> > invoked that needs it, on MS-Windows we load the zlib DLL at run time
> > when requested. See init_zlib_functions in decompress.c. This is
> > unlike on Posix systems, where Emacs is linked with zlib at link time.
> > Does this explain what is going on?
>
> I see, we should probably have comp.c use the necessary DEF_DLL_FN bloat
> or have these functions wrapped in decompress.c.
I think it's better to use functions in decompress.c or add whatever
you need there, and have the new functions use the same paradigm,
which on Windows loads the DLL the first time it is needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 21:24:03 GMT)
Full text and
rfc822 format available.
Message #59 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 18 Dec 2020 16:02:20 +0000
> Cc: 45303 <at> debbugs.gnu.org
> From: Andrea Corallo via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > # patch to look for libgccjit-0.dll instead of libgcc.dll? lisp/term/w32-win.el & src/emacs.c
> > sed -i -e 's/libgccjit.dll/libgccjit-0.dll/' lisp/term/w32-win.el
> > sed -i -e 's/libgccjit.dll/libgccjit-0.dll/' src/emacs.c
>
> I've really no windows knowledge to judge that, perhaps Eli will
> comment. If these are correct fixes you should submit a patch for
> those.
They are correct fixes, since DLLs on Windows usually have the API
number in their names. In this case, I guess the API number is zero,
so libgccjit-0.dll is correct (and libgccjit.dll probably doesn't
exist in Windows installations of GCC/libgccjit).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 21:27:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Liāu, Kiong-Gē 廖宮毅 <gongyi.liao <at> gmail.com>
> Date: Fri, 18 Dec 2020 13:35:02 -0600
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 45303 <at> debbugs.gnu.org,
> =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
>
> make[2]: Entering directory
> '/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
> ELC+ELN ../../src/lisp/emacs-lisp/macroexp.elc
>
> Backtrace:
> 00000004001adbe2
> 00000004000b40a6
> 00000004000ccc64
> 000000040020581a
> 00007ffeba377ff0
> 00007ffebb9910f7
> 00007ffebb93b46c
> 00007ffebb98fc26
This form of backtrace is impossible to interpret on any system but
yours. Please run the failing command under GDB and post the
backtrace from the crash produced by the "bt" GDB command. Or at the
very least use the addr2line program to convert the addresses into a
human-readable backtrace (the Emacs manual explains how in the node
"Crashing").
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 22:25:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Fri, 18 Dec 2020 22:26:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 00:58:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Here's the debug info:
$ gdb --args ./src/bootstrap-emacs.exe -l comp -f
byte-compile-refresh-preload -f
batch-byte-native-compile-for-bootstrap ../src/lisp/macroexpand.el
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
File "<string>", line 3, in <module>
ModuleNotFoundError: No module named 'libstdcxx'
/etc/gdbinit:6: Error in sourced command file:
Error while executing Python code.
Reading symbols from ./src/bootstrap-emacs.exe...
(gdb) start
Temporary breakpoint 1 at 0x400215320: file ../../src/src/emacs.c, line 968.
Starting program:
/home/VWinUser0/Downloads/emacs/native-comp/build/src/bootstrap-emacs.exe
-l comp -f byte-compile-refresh-preload -f
batch-byte-native-compile-for-bootstrap ../src/lisp/macroexpand.el
[New Thread 7800.0x2a24]
[New Thread 7800.0x1fb8]
[New Thread 7800.0x2ae4]
Thread 1 hit Temporary breakpoint 1, main (argc=8, argv=0xc13240) at
../../src/src/emacs.c:968
968 {
(gdb) continue
Continuing.
[New Thread 7800.0x7fc]
[New Thread 7800.0x2abc]
Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffeb8a493e3 in KERNELBASE!DebugBreak () from
/c/WINDOWS/System32/KERNELBASE.dll
(gdb) bt
#0 0x00007ffeb8a493e3 in KERNELBASE!DebugBreak () from
/c/WINDOWS/System32/KERNELBASE.dll
#1 0x00000004001adbbc in emacs_abort () at ../../src/src/w32fns.c:10847
#2 0x000000040009d7cc in bidi_initialize () at ../../src/src/bidi.c:1096
#3 0x00000004000a1285 in bidi_init_it (charpos=charpos <at> entry=1,
bytepos=1, frame_window_p=<optimized out>,
bidi_it=bidi_it <at> entry=0xbfbed0)
at ../../src/src/bidi.c:1138
#4 0x000000040002cd02 in init_iterator (it=it <at> entry=0xbfb4e0,
w=w <at> entry=0x3f160e0, charpos=1, bytepos=<optimized out>,
row=<optimized out>,
row <at> entry=0x0, base_face_id=<optimized out>,
base_face_id <at> entry=DEFAULT_FACE_ID) at ../../src/src/xdisp.c:3436
#5 0x00000004000360b9 in resize_mini_window (w=0x3f160e0,
exact_p=exact_p <at> entry=true) at ../../src/src/xdisp.c:11784
#6 0x000000040000f460 in do_switch_frame (frame=0x5cb82c5,
track=<optimized out>, for_deletion=<optimized out>,
norecord=0xfffffffc03a1a2a8)
at ../../src/src/lisp.h:731
#7 0x00000004001336d6 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#8 0x000000040013397d in Fprogn (body=0x4960b43) at ../../src/src/eval.c:471
#9 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#10 0x0000000400134ced in Funwind_protect (args=0x4960943) at
../../src/src/lisp.h:1420
#11 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#12 0x0000000400134a15 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#13 Flet (args=0x4960913) at ../../src/src/eval.c:1055
#14 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#15 0x0000000400133e9d in Fprogn (body=0x4960893) at ../../src/src/eval.c:471
#16 Fif (args=<optimized out>) at ../../src/src/eval.c:427
#17 Fif (args=<optimized out>) at ../../src/src/eval.c:413
#18 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#19 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#20 funcall_lambda (fun=0x4960813, fun <at> entry=0x2b,
nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfcf50) at
../../src/src/eval.c:3222
#21 0x0000000400134468 in apply_lambda (fun=0x2b, args=<optimized
out>, count=12570672, count <at> entry=43) at ../../src/src/eval.c:3094
#22 0x00000004001332e8 in eval_sub (form=<optimized out>) at
../../src/src/eval.c:2497
#23 0x000000040013397d in Fprogn (body=0x495f82b) at ../../src/src/eval.c:471
#24 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
--Type <RET> for more, q to quit, c to continue without paging--
#25 0x0000000400134ced in Funwind_protect (args=0x495f78b) at
../../src/src/lisp.h:1420
#26 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#27 0x0000000400134c25 in Fprogn (body=0x495f76b) at ../../src/src/eval.c:471
#28 FletX (args=0x495f72b) at ../../src/src/eval.c:987
#29 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#30 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#31 funcall_lambda (fun=0x495f6cb, fun <at> entry=0x24,
nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfd510) at
../../src/src/eval.c:3222
#32 0x0000000400134468 in apply_lambda (fun=0x24, args=<optimized
out>, count=12572144, count <at> entry=36) at ../../src/src/eval.c:3094
#33 0x00000004001332e8 in eval_sub (form=<optimized out>) at
../../src/src/eval.c:2497
#34 0x000000040013397d in Fprogn (body=0x0) at ../../src/src/eval.c:471
#35 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#36 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#37 funcall_lambda (fun=0x495f61b, nargs=nargs <at> entry=1,
arg_vector=arg_vector <at> entry=0xbfd9e8) at ../../src/src/eval.c:3222
#38 0x0000000400130c8f in Ffuncall (nargs=nargs <at> entry=2,
args=args <at> entry=0xbfd9e0) at ../../src/src/eval.c:2961
#39 0x0000000400132fb3 in Fapply (nargs=2, args=0xbfd9e0) at
../../src/src/eval.c:2532
#40 0x0000000400130e07 in Ffuncall (nargs=<optimized out>,
args=args <at> entry=0xbfd9d8) at ../../src/src/lisp.h:2092
#41 0x000000040016dce0 in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>,
args_template=args_template <at> entry=0x202, nargs=nargs <at> entry=1,
args=<optimized out>, args <at> entry=0xbfdbe0) at
../../src/src/bytecode.c:632
#42 0x0000000400134175 in fetch_and_exec_byte_code (args=0xbfdbe0,
nargs=1, syms_left=0x202, fun=0x4152a5d) at ../../src/src/lisp.h:1838
#43 funcall_lambda (fun=0x4152a5d, fun <at> entry=0x1f,
nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfdbe0) at
../../src/src/eval.c:3150
#44 0x0000000400134468 in apply_lambda (fun=0x1f, args=<optimized
out>, count=12573888, count <at> entry=31) at ../../src/src/eval.c:3094
#45 0x00000004001332e8 in eval_sub (form=<optimized out>) at
../../src/src/eval.c:2497
#46 0x0000000400134a15 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#47 Flet (args=0x415293b) at ../../src/src/eval.c:1055
#48 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#49 0x00000004001339f3 in Fsetq (args=<optimized out>) at
../../src/src/eval.c:518
#50 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#51 0x0000000400134c25 in Fprogn (body=0x414e44b) at ../../src/src/eval.c:471
--Type <RET> for more, q to quit, c to continue without paging--
#52 FletX (args=0x414e3db) at ../../src/src/eval.c:987
#53 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#54 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#55 funcall_lambda (fun=0x414e37b, fun <at> entry=0x18,
nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfe220) at
../../src/src/eval.c:3222
#56 0x0000000400134468 in apply_lambda (fun=0x18, args=<optimized
out>, count=12575488, count <at> entry=24) at ../../src/src/eval.c:3094
#57 0x00000004001332e8 in eval_sub (form=<optimized out>) at
../../src/src/eval.c:2497
#58 0x00000004001339f3 in Fsetq (args=<optimized out>) at
../../src/src/eval.c:518
#59 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#60 0x00000004001339f3 in Fsetq (args=<optimized out>) at
../../src/src/eval.c:518
#61 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#62 0x000000040013397d in Fprogn (body=0x490455b) at ../../src/src/eval.c:471
#63 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#64 0x000000040013390d in For (args=0x0) at ../../src/src/eval.c:384
#65 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#66 0x000000040013397d in Fprogn (body=0x49043bb) at ../../src/src/eval.c:471
#67 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#68 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#69 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#70 funcall_lambda (fun=0x490432b, fun <at> entry=0x10,
nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbfeaf0) at
../../src/src/eval.c:3222
#71 0x0000000400134468 in apply_lambda (fun=0x10, args=<optimized
out>, count=12577728, count <at> entry=16) at ../../src/src/eval.c:3094
#72 0x00000004001332e8 in eval_sub (form=<optimized out>) at
../../src/src/eval.c:2497
#73 0x0000000400133e9d in Fprogn (body=0x0) at ../../src/src/eval.c:471
#74 Fif (args=<optimized out>) at ../../src/src/eval.c:427
#75 Fif (args=<optimized out>) at ../../src/src/eval.c:413
#76 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#77 0x0000000400134a15 in Fprogn (body=0x48edfc3) at ../../src/src/eval.c:471
#78 Flet (args=0x48edeb3) at ../../src/src/eval.c:1055
#79 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
--Type <RET> for more, q to quit, c to continue without paging--
#80 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#81 funcall_lambda (fun=0x48ede63, fun <at> entry=0xb, nargs=nargs <at> entry=0,
arg_vector=arg_vector <at> entry=0xbfefa0) at ../../src/src/eval.c:3222
#82 0x0000000400134468 in apply_lambda (fun=0xb, args=<optimized out>,
count=12578928, count <at> entry=11) at ../../src/src/eval.c:3094
#83 0x00000004001332e8 in eval_sub (form=<optimized out>) at
../../src/src/eval.c:2497
#84 0x0000000400134ced in Funwind_protect (args=0x4c17743) at
../../src/src/lisp.h:1420
#85 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#86 0x0000000400134a15 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#87 Flet (args=0x4c17713) at ../../src/src/eval.c:1055
#88 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#89 0x0000000400133e9d in Fprogn (body=0x4c171e3) at ../../src/src/eval.c:471
#90 Fif (args=<optimized out>) at ../../src/src/eval.c:427
#91 Fif (args=<optimized out>) at ../../src/src/eval.c:413
#92 0x0000000400133713 in eval_sub (form=<optimized out>) at
../../src/src/lisp.h:2092
#93 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
#94 funcall_lambda (fun=0x4c17023, fun <at> entry=0x4, nargs=nargs <at> entry=0,
arg_vector=arg_vector <at> entry=0xbff580) at ../../src/src/eval.c:3222
#95 0x0000000400134468 in apply_lambda (fun=0x4, args=<optimized out>,
count=12580432, count <at> entry=4) at ../../src/src/eval.c:3094
#96 0x00000004001332e8 in eval_sub (form=form <at> entry=0x4d83093) at
../../src/src/eval.c:2497
#97 0x000000040013508d in Feval (form=0x4d83093, lexical=<optimized
out>) at ../../src/src/eval.c:2249
#98 0x000000040012fd3d in internal_condition_case
(bfun=bfun <at> entry=0x4000b47f0 <top_level_2>,
handlers=handlers <at> entry=0x90,
hfun=hfun <at> entry=0x4000bad30 <cmd_error>) at ../../src/src/eval.c:1424
#99 0x00000004000b561d in top_level_1 (ignore=<optimized out>) at
../../src/src/lisp.h:1008
#100 0x000000040012fcab in internal_catch (tag=tag <at> entry=0xec10,
func=func <at> entry=0x4000b55f0 <top_level_1>, arg=arg <at> entry=0x0)
at ../../src/src/eval.c:1185
#101 0x00000004000b4715 in command_loop () at ../../src/src/lisp.h:1008
#102 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
However I cannot tell what's the major cause of the error.
On Fri, Dec 18, 2020 at 3:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Liāu, Kiong-Gē 廖宮毅 <gongyi.liao <at> gmail.com>
> > Date: Fri, 18 Dec 2020 13:35:02 -0600
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 45303 <at> debbugs.gnu.org,
> > =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> >
> > make[2]: Entering directory
> > '/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
> > ELC+ELN ../../src/lisp/emacs-lisp/macroexp.elc
> >
> > Backtrace:
> > 00000004001adbe2
> > 00000004000b40a6
> > 00000004000ccc64
> > 000000040020581a
> > 00007ffeba377ff0
> > 00007ffebb9910f7
> > 00007ffebb93b46c
> > 00007ffebb98fc26
>
> This form of backtrace is impossible to interpret on any system but
> yours. Please run the failing command under GDB and post the
> backtrace from the crash produced by the "bt" GDB command. Or at the
> very least use the addr2line program to convert the addresses into a
> human-readable backtrace (the Emacs manual explains how in the node
> "Crashing").
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 05:40:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 45303 <at> debbugs.gnu.org (full text, mbox):
I just tested the master branch and confirmed that master branch does
not have this issue
On Fri, Dec 18, 2020 at 6:57 PM Liāu, Kiong-Gē 廖宮毅
<gongyi.liao <at> gmail.com> wrote:
>
> Here's the debug info:
>
> $ gdb --args ./src/bootstrap-emacs.exe -l comp -f
> byte-compile-refresh-preload -f
> batch-byte-native-compile-for-bootstrap ../src/lisp/macroexpand.el
> GNU gdb (GDB) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-pc-msys".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Traceback (most recent call last):
> File "<string>", line 3, in <module>
> ModuleNotFoundError: No module named 'libstdcxx'
> /etc/gdbinit:6: Error in sourced command file:
> Error while executing Python code.
> Reading symbols from ./src/bootstrap-emacs.exe...
> (gdb) start
> Temporary breakpoint 1 at 0x400215320: file ../../src/src/emacs.c, line 968.
> Starting program:
> /home/VWinUser0/Downloads/emacs/native-comp/build/src/bootstrap-emacs.exe
> -l comp -f byte-compile-refresh-preload -f
> batch-byte-native-compile-for-bootstrap ../src/lisp/macroexpand.el
> [New Thread 7800.0x2a24]
> [New Thread 7800.0x1fb8]
> [New Thread 7800.0x2ae4]
>
> Thread 1 hit Temporary breakpoint 1, main (argc=8, argv=0xc13240) at
> ../../src/src/emacs.c:968
> 968 {
> (gdb) continue
> Continuing.
> [New Thread 7800.0x7fc]
> [New Thread 7800.0x2abc]
>
> Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffeb8a493e3 in KERNELBASE!DebugBreak () from
> /c/WINDOWS/System32/KERNELBASE.dll
> (gdb) bt
> #0 0x00007ffeb8a493e3 in KERNELBASE!DebugBreak () from
> /c/WINDOWS/System32/KERNELBASE.dll
> #1 0x00000004001adbbc in emacs_abort () at ../../src/src/w32fns.c:10847
> #2 0x000000040009d7cc in bidi_initialize () at ../../src/src/bidi.c:1096
> #3 0x00000004000a1285 in bidi_init_it (charpos=charpos <at> entry=1,
> bytepos=1, frame_window_p=<optimized out>,
> bidi_it=bidi_it <at> entry=0xbfbed0)
> at ../../src/src/bidi.c:1138
> #4 0x000000040002cd02 in init_iterator (it=it <at> entry=0xbfb4e0,
> w=w <at> entry=0x3f160e0, charpos=1, bytepos=<optimized out>,
> row=<optimized out>,
> row <at> entry=0x0, base_face_id=<optimized out>,
> base_face_id <at> entry=DEFAULT_FACE_ID) at ../../src/src/xdisp.c:3436
> #5 0x00000004000360b9 in resize_mini_window (w=0x3f160e0,
> exact_p=exact_p <at> entry=true) at ../../src/src/xdisp.c:11784
> #6 0x000000040000f460 in do_switch_frame (frame=0x5cb82c5,
> track=<optimized out>, for_deletion=<optimized out>,
> norecord=0xfffffffc03a1a2a8)
> at ../../src/src/lisp.h:731
> #7 0x00000004001336d6 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #8 0x000000040013397d in Fprogn (body=0x4960b43) at ../../src/src/eval.c:471
> #9 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #10 0x0000000400134ced in Funwind_protect (args=0x4960943) at
> ../../src/src/lisp.h:1420
> #11 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #12 0x0000000400134a15 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #13 Flet (args=0x4960913) at ../../src/src/eval.c:1055
> #14 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #15 0x0000000400133e9d in Fprogn (body=0x4960893) at ../../src/src/eval.c:471
> #16 Fif (args=<optimized out>) at ../../src/src/eval.c:427
> #17 Fif (args=<optimized out>) at ../../src/src/eval.c:413
> #18 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #19 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #20 funcall_lambda (fun=0x4960813, fun <at> entry=0x2b,
> nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfcf50) at
> ../../src/src/eval.c:3222
> #21 0x0000000400134468 in apply_lambda (fun=0x2b, args=<optimized
> out>, count=12570672, count <at> entry=43) at ../../src/src/eval.c:3094
> #22 0x00000004001332e8 in eval_sub (form=<optimized out>) at
> ../../src/src/eval.c:2497
> #23 0x000000040013397d in Fprogn (body=0x495f82b) at ../../src/src/eval.c:471
> #24 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> --Type <RET> for more, q to quit, c to continue without paging--
> #25 0x0000000400134ced in Funwind_protect (args=0x495f78b) at
> ../../src/src/lisp.h:1420
> #26 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #27 0x0000000400134c25 in Fprogn (body=0x495f76b) at ../../src/src/eval.c:471
> #28 FletX (args=0x495f72b) at ../../src/src/eval.c:987
> #29 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #30 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #31 funcall_lambda (fun=0x495f6cb, fun <at> entry=0x24,
> nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfd510) at
> ../../src/src/eval.c:3222
> #32 0x0000000400134468 in apply_lambda (fun=0x24, args=<optimized
> out>, count=12572144, count <at> entry=36) at ../../src/src/eval.c:3094
> #33 0x00000004001332e8 in eval_sub (form=<optimized out>) at
> ../../src/src/eval.c:2497
> #34 0x000000040013397d in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #35 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #36 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #37 funcall_lambda (fun=0x495f61b, nargs=nargs <at> entry=1,
> arg_vector=arg_vector <at> entry=0xbfd9e8) at ../../src/src/eval.c:3222
> #38 0x0000000400130c8f in Ffuncall (nargs=nargs <at> entry=2,
> args=args <at> entry=0xbfd9e0) at ../../src/src/eval.c:2961
> #39 0x0000000400132fb3 in Fapply (nargs=2, args=0xbfd9e0) at
> ../../src/src/eval.c:2532
> #40 0x0000000400130e07 in Ffuncall (nargs=<optimized out>,
> args=args <at> entry=0xbfd9d8) at ../../src/src/lisp.h:2092
> #41 0x000000040016dce0 in exec_byte_code (bytestr=<optimized out>,
> vector=<optimized out>, maxdepth=<optimized out>,
> args_template=args_template <at> entry=0x202, nargs=nargs <at> entry=1,
> args=<optimized out>, args <at> entry=0xbfdbe0) at
> ../../src/src/bytecode.c:632
> #42 0x0000000400134175 in fetch_and_exec_byte_code (args=0xbfdbe0,
> nargs=1, syms_left=0x202, fun=0x4152a5d) at ../../src/src/lisp.h:1838
> #43 funcall_lambda (fun=0x4152a5d, fun <at> entry=0x1f,
> nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfdbe0) at
> ../../src/src/eval.c:3150
> #44 0x0000000400134468 in apply_lambda (fun=0x1f, args=<optimized
> out>, count=12573888, count <at> entry=31) at ../../src/src/eval.c:3094
> #45 0x00000004001332e8 in eval_sub (form=<optimized out>) at
> ../../src/src/eval.c:2497
> #46 0x0000000400134a15 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #47 Flet (args=0x415293b) at ../../src/src/eval.c:1055
> #48 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #49 0x00000004001339f3 in Fsetq (args=<optimized out>) at
> ../../src/src/eval.c:518
> #50 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #51 0x0000000400134c25 in Fprogn (body=0x414e44b) at ../../src/src/eval.c:471
> --Type <RET> for more, q to quit, c to continue without paging--
> #52 FletX (args=0x414e3db) at ../../src/src/eval.c:987
> #53 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #54 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #55 funcall_lambda (fun=0x414e37b, fun <at> entry=0x18,
> nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0xbfe220) at
> ../../src/src/eval.c:3222
> #56 0x0000000400134468 in apply_lambda (fun=0x18, args=<optimized
> out>, count=12575488, count <at> entry=24) at ../../src/src/eval.c:3094
> #57 0x00000004001332e8 in eval_sub (form=<optimized out>) at
> ../../src/src/eval.c:2497
> #58 0x00000004001339f3 in Fsetq (args=<optimized out>) at
> ../../src/src/eval.c:518
> #59 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #60 0x00000004001339f3 in Fsetq (args=<optimized out>) at
> ../../src/src/eval.c:518
> #61 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #62 0x000000040013397d in Fprogn (body=0x490455b) at ../../src/src/eval.c:471
> #63 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #64 0x000000040013390d in For (args=0x0) at ../../src/src/eval.c:384
> #65 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #66 0x000000040013397d in Fprogn (body=0x49043bb) at ../../src/src/eval.c:471
> #67 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #68 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #69 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #70 funcall_lambda (fun=0x490432b, fun <at> entry=0x10,
> nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0xbfeaf0) at
> ../../src/src/eval.c:3222
> #71 0x0000000400134468 in apply_lambda (fun=0x10, args=<optimized
> out>, count=12577728, count <at> entry=16) at ../../src/src/eval.c:3094
> #72 0x00000004001332e8 in eval_sub (form=<optimized out>) at
> ../../src/src/eval.c:2497
> #73 0x0000000400133e9d in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #74 Fif (args=<optimized out>) at ../../src/src/eval.c:427
> #75 Fif (args=<optimized out>) at ../../src/src/eval.c:413
> #76 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #77 0x0000000400134a15 in Fprogn (body=0x48edfc3) at ../../src/src/eval.c:471
> #78 Flet (args=0x48edeb3) at ../../src/src/eval.c:1055
> #79 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> --Type <RET> for more, q to quit, c to continue without paging--
> #80 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #81 funcall_lambda (fun=0x48ede63, fun <at> entry=0xb, nargs=nargs <at> entry=0,
> arg_vector=arg_vector <at> entry=0xbfefa0) at ../../src/src/eval.c:3222
> #82 0x0000000400134468 in apply_lambda (fun=0xb, args=<optimized out>,
> count=12578928, count <at> entry=11) at ../../src/src/eval.c:3094
> #83 0x00000004001332e8 in eval_sub (form=<optimized out>) at
> ../../src/src/eval.c:2497
> #84 0x0000000400134ced in Funwind_protect (args=0x4c17743) at
> ../../src/src/lisp.h:1420
> #85 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #86 0x0000000400134a15 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #87 Flet (args=0x4c17713) at ../../src/src/eval.c:1055
> #88 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #89 0x0000000400133e9d in Fprogn (body=0x4c171e3) at ../../src/src/eval.c:471
> #90 Fif (args=<optimized out>) at ../../src/src/eval.c:427
> #91 Fif (args=<optimized out>) at ../../src/src/eval.c:413
> #92 0x0000000400133713 in eval_sub (form=<optimized out>) at
> ../../src/src/lisp.h:2092
> #93 0x0000000400134265 in Fprogn (body=0x0) at ../../src/src/eval.c:471
> #94 funcall_lambda (fun=0x4c17023, fun <at> entry=0x4, nargs=nargs <at> entry=0,
> arg_vector=arg_vector <at> entry=0xbff580) at ../../src/src/eval.c:3222
> #95 0x0000000400134468 in apply_lambda (fun=0x4, args=<optimized out>,
> count=12580432, count <at> entry=4) at ../../src/src/eval.c:3094
> #96 0x00000004001332e8 in eval_sub (form=form <at> entry=0x4d83093) at
> ../../src/src/eval.c:2497
> #97 0x000000040013508d in Feval (form=0x4d83093, lexical=<optimized
> out>) at ../../src/src/eval.c:2249
> #98 0x000000040012fd3d in internal_condition_case
> (bfun=bfun <at> entry=0x4000b47f0 <top_level_2>,
> handlers=handlers <at> entry=0x90,
> hfun=hfun <at> entry=0x4000bad30 <cmd_error>) at ../../src/src/eval.c:1424
> #99 0x00000004000b561d in top_level_1 (ignore=<optimized out>) at
> ../../src/src/lisp.h:1008
> #100 0x000000040012fcab in internal_catch (tag=tag <at> entry=0xec10,
> func=func <at> entry=0x4000b55f0 <top_level_1>, arg=arg <at> entry=0x0)
> at ../../src/src/eval.c:1185
> #101 0x00000004000b4715 in command_loop () at ../../src/src/lisp.h:1008
> #102 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> However I cannot tell what's the major cause of the error.
>
> On Fri, Dec 18, 2020 at 3:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Liāu, Kiong-Gē 廖宮毅 <gongyi.liao <at> gmail.com>
> > > Date: Fri, 18 Dec 2020 13:35:02 -0600
> > > Cc: Eli Zaretskii <eliz <at> gnu.org>, 45303 <at> debbugs.gnu.org,
> > > =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
> > >
> > > make[2]: Entering directory
> > > '/home/VWinUser0/Downloads/emacs/native-comp/build/lisp'
> > > ELC+ELN ../../src/lisp/emacs-lisp/macroexp.elc
> > >
> > > Backtrace:
> > > 00000004001adbe2
> > > 00000004000b40a6
> > > 00000004000ccc64
> > > 000000040020581a
> > > 00007ffeba377ff0
> > > 00007ffebb9910f7
> > > 00007ffebb93b46c
> > > 00007ffebb98fc26
> >
> > This form of backtrace is impossible to interpret on any system but
> > yours. Please run the failing command under GDB and post the
> > backtrace from the crash produced by the "bt" GDB command. Or at the
> > very least use the addr2line program to convert the addresses into a
> > human-readable backtrace (the Emacs manual explains how in the node
> > "Crashing").
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 07:58:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Pal Gloss <pcfeb0009 <at> gmx.com> writes:
> I retried building with the most recent feature/native-comp branch and if you
> skip to the last code block, you can see how I managed to build emacs with it
> and use it (I've been using a similar build on Win10 for about 2 days). I can
> confirm that my previous hack for =nt/epaths.nt= is not needed anymore.
>
> #+begin_src shell :exports code
> git rev-parse HEAD feature/native-comp
> #+end_src
> : 87f6e937995c433825173fb0473a801791d5beac
> : 87f6e937995c433825173fb0473a801791d5beac
[...]
> # patch to look for libgccjit-0.dll instead of libgcc.dll in lisp/term/w32-win.el & src/emacs.c
> sed -i -e 's/libgccjit.dll/libgccjit-0.dll/' lisp/term/w32-win.el
> sed -i -e 's/libgccjit.dll/libgccjit-0.dll/' src/emacs.c
Okay this should be fixed by now.
> mkdir -p ../build
> cd ../build
> ../emacs/configure \
> --with-xml2 \
> --without-pop \
> --prefix="/home/cramaph1/$EMACS_VERSION/dest" \
> --without-compress-install \
> --without-dbus \
> --with-nativecomp \
> --with-modules 'CFLAGS=-O2 -g3'
> # fix linker errors by making sure the correct libraries are added to the linker command
> sed -i -e 's/^LIBGCCJIT = *$/LIBGCCJIT = -lz -lgccjit/' src/Makefile
> make -j"$PROCESSORS_TO_USE"
> #+end_src
>
> Now I get a crash with a backtrace:
> #+begin_example
> Backtrace:
> 00000004001afb22
> 00000004000b40a6
> 00000004000ccc64
> 000000040020a4ca
> 00007ff9e5f58040
> 00007ff9e6181847
> 00007ff9e614a881
> 00007ff9e61804b6
> make[2]: *** [Makefile:297: ../../emacs/lisp/term/w32-win.elc] Error 3
> make[1]: *** [Makefile:797: ../../emacs/lisp/term/w32-win.elc] Error 2
> make[1]: Leaving directory '/home/cramaph1/emacs-native-comp/build/src'
> make: *** [Makefile:434: src] Error 2
> #+end_example
>
> This crash is due to the =#pragma GCC diagnostic= around a =if
> (gcc_jit_global_set_initializer)=: see this example program where the
> =#pragma= around the =if(...)= makes it into a separate statement from the
> ={...}= body. Apparently, on my machine, =gcc_jit_global_set_initializer= is
> NULL but the body gets executed anyway.
> #+begin_src c :exports code
> /* save as /tmp/t.c, then run (cd /tmp && gcc t.c && ./a.exe) */
> /* It should print nothing at all, but on my machine, it prints
> This should not be printed, but will be printed anyway (2).
> This is gcc.exe (Rev6, Built by MSYS2 project) 10.2.0 */
> #include <stdio.h>
> int main() {
> if (0)
> {
> printf("This will not be printed (1).\n");
> }
> #pragma GCC diagnostic ignored "-Waddress"
> if (0)
> #pragma GCC diagnostic pop
> {
> printf("This should not be printed, but will be printed anyway (2).\n");
> }
> #pragma GCC diagnostic ignored "-Waddress"
> if (0)
> {
> #pragma GCC diagnostic pop
> printf("This should not be printed (3).\n");
> }
> return 0;
> }
> #+end_src
>
> So I try again, this time inverting the =#pragma GCC diagnostic pop= and the ={= lines, too:
> #+begin_src shell :exports code
> cd ../emacs
> rm -rf ../build
> git restore .
> # patch to avoid gcc_jit_global_set_initializer (crashes on my machine...; it
> # seems there is an interaction with the #pragma and the rest of the parsing
> # because the statement is incomplete?) and to adapt to (new) 5th parameter to
> # directory-files
Nice :)
While reporting the bug in GCC I've found this previous bugzilla report.
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696>
Interesting... should work now.
> sed -i -e '/if (gcc_jit_global_set_initializer)/,/{/ {
> /#pragma GCC diagnostic pop/d
> /{/a #pragma GCC diagnostic pop
> }' \
> -e '/internal_condition_case_4/,/FOR_EACH/ {
> s/internal_condition_case_4/internal_condition_case_5/
> s/Qt, return_nil);/Qnil, Qt, return_nil);/
> }' \
> src/comp.c
> sed -i -e '/extern Lisp_Object internal_condition_case_4/a extern Lisp_Object internal_condition_case_5 (Lisp_Object
> (*) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));' src/lisp.h
> sed -i -e '/Like internal_condition_case_1 but call BFUN with ARG1, ARG2, ARG3, ARG4 as/ {
> s/ARG4 as/ARG4, ARG5 as/
> a its arguments. */
> a Lisp_Object
> a internal_condition_case_5 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object,
> a Lisp_Object, Lisp_Object,
> a Lisp_Object),
> a Lisp_Object arg1, Lisp_Object arg2,
> a Lisp_Object arg3, Lisp_Object arg4,
> a Lisp_Object arg5,
> a Lisp_Object handlers,
> a Lisp_Object (*hfun) (Lisp_Object))
> a {
> a struct handler *c = push_handler (handlers, CONDITION_CASE);
> a if (sys_setjmp (c->jmp))
> a {
> a Lisp_Object val = handlerlist->val;
> a clobbered_eassert (handlerlist == c);
> a handlerlist = handlerlist->next;
> a return hfun (val);
> a }
> a else
> a {
> a Lisp_Object val = bfun (arg1, arg2, arg3, arg4, arg5);
> a eassert (handlerlist == c);
> a handlerlist = c->next;
> a return val;
> a }
> a }
> a /* Like internal_condition_case_1 but call BFUN with ARG1, ARG2, ARG3, ARG4 as
> }' src/eval.c
Should be fixed too.
[...]
> And now emacs 28.0.50 seems to work (there are some compilation issues with
> hyperbole, but my config is usable). If I do =M-: (apropos-value
> ’("%emacs_dir%") nil)=, I still see these directories that look fishy, but
> <F1> i works for me at the moment.
> #+begin_example
> Info-default-directory-list
> ("%emacs_dir%/share/info/")
> ----------------
> configure-info-directory
> "%emacs_dir%/share/info"
> #+end_example
Right so (unless I'm forgetting something) just the zlib linker error
should be remaining, correct?
I'll have a look later in the weekend or Monday.
> Sorry for the wall of text, I am just trying to show that I built up my
> hacks/patches step by step and make sure they are still needed.
Thanks for the precise analysis this is very helpful.
The Windows port is a bit rusty, I believe nobody compiled it since 6+
months, is good we resurrect it and keep it running.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 08:06:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Liāu, Kiong-Gē 廖宮毅 <gongyi.liao <at> gmail.com>
> Date: Fri, 18 Dec 2020 18:57:37 -0600
> Cc: Andrea Corallo <akrl <at> sdf.org>, 45303 <at> debbugs.gnu.org
>
> Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
> 0x00007ffeb8a493e3 in KERNELBASE!DebugBreak () from
> /c/WINDOWS/System32/KERNELBASE.dll
> (gdb) bt
> #0 0x00007ffeb8a493e3 in KERNELBASE!DebugBreak () from
> /c/WINDOWS/System32/KERNELBASE.dll
> #1 0x00000004001adbbc in emacs_abort () at ../../src/src/w32fns.c:10847
> #2 0x000000040009d7cc in bidi_initialize () at ../../src/src/bidi.c:1096
This means Emacs was started without the uni-bidi.el file being
available. Or maybe that file failed to load (because of some previous
problem in the build). E.g., perhaps there's an invalid uni-bidi.eln
file, and Emacs tried to load it in preference to .el/.elc file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 14:36:02 GMT)
Full text and
rfc822 format available.
Message #83 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sat 19 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Right so (unless I'm forgetting something) just the zlib linker error
> should be remaining, correct?
>
> I'll have a look later in the weekend or Monday.
AS well as the zlib issue, there are two other problems that I found
when trying to build using MSYS2 Mingw64 64bit:
a) Linker error for "gcc_jit_type_get_const".
It looks like this does not have a runtime import in comp.c, so is
just a matter of fixing up another DLL import.
b) Linker error for "strsignal"
This seems to be a configure problem. On master the configure test
for strsignal fails to link, and the gnulib replacement get used.
On the native branch the configure test links successfully, so the
gnulib replacement does not happen. The only difference in the
conftest command line appears to be adding libgccjit, so somehow
that library is providing a strsignal symbol.
Adding "ac_cv_func_strsignal=no" in nt/mingw-cfg.site appears to
suppress this problem, but I don't know if that is the right fix.
HTH
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 16:16:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Sat, 19 Dec 2020 14:35:45 +0000
>
> b) Linker error for "strsignal"
> This seems to be a configure problem. On master the configure test
> for strsignal fails to link, and the gnulib replacement get used.
> On the native branch the configure test links successfully, so the
> gnulib replacement does not happen. The only difference in the
> conftest command line appears to be adding libgccjit, so somehow
> that library is providing a strsignal symbol.
> Adding "ac_cv_func_strsignal=no" in nt/mingw-cfg.site appears to
> suppress this problem, but I don't know if that is the right fix.
I must be missing something, because I don't see strsignal used on
master in the MinGW build at all. Moreover, Gnulib's strsignal.c is
not even in lib/. We call sigdescr_np instead. So I wonder how did
you see that the Gnulib replacement for strsignal is used on master in
the Windows build.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 17:16:01 GMT)
Full text and
rfc822 format available.
Message #89 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sat 19 Dec 2020, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Sat, 19 Dec 2020 14:35:45 +0000
>>
>> b) Linker error for "strsignal"
>> This seems to be a configure problem. On master the configure test
>> for strsignal fails to link, and the gnulib replacement get used.
>> On the native branch the configure test links successfully, so the
>> gnulib replacement does not happen. The only difference in the
>> conftest command line appears to be adding libgccjit, so somehow
>> that library is providing a strsignal symbol.
>> Adding "ac_cv_func_strsignal=no" in nt/mingw-cfg.site appears to
>> suppress this problem, but I don't know if that is the right fix.
>
> I must be missing something, because I don't see strsignal used on
> master in the MinGW build at all. Moreover, Gnulib's strsignal.c is
> not even in lib/. We call sigdescr_np instead. So I wonder how did
> you see that the Gnulib replacement for strsignal is used on master in
> the Windows build.
Entirely possible that I have misunderstood something from reading
sources and grepping (the gnulib gyrations are hard to follow).
The emacs source calls strsignal, and something provides it (whether via
a macro replacement or a linkable symbol). The only difference I could
see was the configure test, as noted above.
I see that src/syssignal.h has a replacement macro:
#ifndef HAVE_STRSIGNAL
# define strsignal(sig) safe_strsignal (sig)
#endif
So is the problem that on the native branch the configure test succeeds
and sets HAVE_STRSIGNAL, resulting in trying to link the wrong symbol ?
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 17:39:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Sat, 19 Dec 2020 17:15:02 +0000
>
> > I must be missing something, because I don't see strsignal used on
> > master in the MinGW build at all. Moreover, Gnulib's strsignal.c is
> > not even in lib/. We call sigdescr_np instead. So I wonder how did
> > you see that the Gnulib replacement for strsignal is used on master in
> > the Windows build.
>
> Entirely possible that I have misunderstood something from reading
> sources and grepping (the gnulib gyrations are hard to follow).
>
> The emacs source calls strsignal, and something provides it (whether via
> a macro replacement or a linkable symbol). The only difference I could
> see was the configure test, as noted above.
The ultimate test is this:
gdb ./emacs.exe
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
...
(gdb) rbreak strsignal
On my system, I see just this:
Breakpoint 2 at 0x119b88b: file sysdep.c, line 2617.
const char *safe_strsignal(int);
> I see that src/syssignal.h has a replacement macro:
>
> #ifndef HAVE_STRSIGNAL
> # define strsignal(sig) safe_strsignal (sig)
> #endif
>
> So is the problem that on the native branch the configure test succeeds
> and sets HAVE_STRSIGNAL, resulting in trying to link the wrong symbol ?
Possibly. The question is, how come the test succeeds? Can you look
in libjccjit.a with "nm -A" and see if it exports strsignal?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 17:57:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Andrea, Pal and Eli,
Scripts in Pal's org file work, the eln compilation works smoothly.
If Pal is using the msys2 version same as the one I use, the
GCC/GccJit version's is 10.2.0
Thanks,
Kiong-Ge
On Thu, Dec 17, 2020 at 3:10 PM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Thu, 17 Dec 2020 20:57:29 +0000
> >> Cc: 45303 <at> debbugs.gnu.org
> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> I've pushed 174f2a92eb, could you please have a try? I've no windows machine on
> >> to test it myself.
> >
> > Don't you need to update also the epaths-force-w32 target in
> > Makefile.in?
>
> Uops, pushed 87f6e93799 thanks
>
> Andrea
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 18:08:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Hi,
thank you for the quick fixes
I do not understand 3b53a591faed03679382a601b93da7fe6ce3b4af: the way I saw the problem is that directory-files now takes an optional COUNT parameter (see thread starting with https://lists.gnu.org/archive/html/emacs-devel/2020-10/msg00691.htmlhttps://lists.gnu.org/archive/html/emacs-devel/2020-10/msg00691.htm) so that the compiler rightly warned that we passed a function expecting 5 parameters to internal_condition_case_4 that works with a pointer to a function with 4 arguments. I did not see any special warning anymore and haven't seen it crash yet, so the change is probably OK.
> > #+begin_example
> > Info-default-directory-list
> > ("%emacs_dir%/share/info/")
> > ----------------
> > configure-info-directory
> > "%emacs_dir%/share/info"
> > #+end_example
I just checked and these %emacs_dir% are also present in a "normal" emacs 27.1 (installed via msys2/mingw pacman, not self-built).
> Right so (unless I'm forgetting something) just the zlib linker error
> should be remaining, correct?
It was not only zlib that was missing, but also gccjit (my hack sets both: LIBGCCJIT = -lz -lgccjit)
> The Windows port is a bit rusty, I believe nobody compiled it since 6+
> months, is good we resurrect it and keep it running.
I was not able to build libgccjit before, but now it is in MSYS2/MINGW pacman, I can build from time to time.
Kind regards,
--
Pal Gloss
For reference, here are the commands I used for my latest build
#+begin_src shell :exports code
git rev-parse HEAD feature/native-comp ; gcc --version
#+end_src
: 3b53a591faed03679382a601b93da7fe6ce3b4af
: 3b53a591faed03679382a601b93da7fe6ce3b4af
: gcc.exe (Rev6, Built by MSYS2 project) 10.2.0
: Copyright (C) 2020 Free Software Foundation, Inc.
: This is free software; see the source for copying conditions. There is NO
: warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* Linker errors
There are 2 linker errors that prevent advancing: zlib and libgccjit.
There is also an issue with strsignal which I will not care about just yet
: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: comp.o: in function `md5_gz_stream':
: C:\msys64\home\cramaph1\emacs-native-comp\build\src/../../emacs/src/comp.c:713: undefined reference to `inflateInit2_'
: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\cramaph1\emacs-native-comp\build\src/../../emacs/src/comp.c:730: undefined reference to `inflate'
: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\cramaph1\emacs-native-comp\build\src/../../emacs/src/comp.c:741: undefined reference to `inflateEnd'
: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\cramaph1\emacs-native-comp\build\src/../../emacs/src/comp.c:741: undefined reference to `inflateEnd'
: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: comp.o: in function `declare_imported_func':
: C:\msys64\home\cramaph1\emacs-native-comp\build\src/../../emacs/src/comp.c:973: undefined reference to `gcc_jit_type_get_const'
#+begin_src shell :exports code
pacman -S --needed base-devel \
mingw-w64-x86_64-toolchain \
mingw-w64-x86_64-xpm-nox \
mingw-w64-x86_64-libtiff \
mingw-w64-x86_64-giflib \
mingw-w64-x86_64-libpng \
mingw-w64-x86_64-libjpeg-turbo \
mingw-w64-x86_64-librsvg \
mingw-w64-x86_64-lcms2 \
mingw-w64-x86_64-jansson \
mingw-w64-x86_64-libxml2 \
mingw-w64-x86_64-gnutls \
mingw-w64-x86_64-zlib \
mingw-w64-x86_64-harfbuzz \
mingw-w64-x86_64-libgccjit
PROCESSORS_TO_USE="3"
EMACS_VERSION=emacs-native-comp
./autogen.sh
mkdir -p ../build
cd ../build
../emacs/configure \
--with-xml2 \
--without-pop \
--prefix="/home/cramaph1/$EMACS_VERSION/dest" \
--without-compress-install \
--without-dbus \
--with-nativecomp \
--with-modules 'CFLAGS=-O2 -g3'
# fix 2 linker errors by making sure the correct libraries are added to the linker command
sed -i -e 's/^LIBGCCJIT = *$/LIBGCCJIT = -lz -lgccjit/' src/Makefile
make -j"$PROCESSORS_TO_USE" && make install
#+end_src
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 19:09:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 19:31:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Pal Gloss <pcfeb0009 <at> gmx.com>
> Date: Sat, 19 Dec 2020 20:08:07 +0100
> Sensitivity: Normal
> Cc: 45303 <at> debbugs.gnu.org
>
> strsignal is in libgccjit.dll.a but not in libgccjit-0.dll:
> $ for f in /mingw64/bin/libgccjit-0.dll /mingw64/lib/libgccjit.dll.a ; do (nm -A "$f" | grep strsignal) || echo "Not
> found in $f" ; done
> Not found in /mingw64/bin/libgccjit-0.dll
Did you try to use pexports to see if the DLL exports strsignal?
> C:/msys64/mingw64/lib/libgccjit.dll.a:d025724.o:0000000000000000 I __imp_strsignal
> C:/msys64/mingw64/lib/libgccjit.dll.a:d025724.o:0000000000000000 T strsignal
This probably means the configure-time test for strsignal should be
moved to before the test for libgccjit.
But in general, I'd suggest to file a bug report with MSYS2 folks:
the DLL and the import library shouldn't export strsignal.
> (gdb) rbreak strsignal
> Breakpoint 1 at 0x4000ce210: file ../../emacs/src/sysdep.c, line 2616.
> const char *safe_strsignal(int);
> Breakpoint 2 at 0x400209fc8
> <function, no debug info> strsignal;
And that latter function is in libgccjit DLL?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 20:41:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Pal Gloss <pcfeb0009 <at> gmx.com> writes:
> Hi,
>
> thank you for the quick fixes
>
> I do not understand 3b53a591faed03679382a601b93da7fe6ce3b4af: the way
No you are right, this morning I was a little in a rush and I might have
failed grepping, hopefully ab985f41db is better.
[...]
> I just checked and these %emacs_dir% are also present in a "normal" emacs 27.1 (installed via msys2/mingw pacman, not self-built).
>
>> Right so (unless I'm forgetting something) just the zlib linker error
>> should be remaining, correct?
>
> It was not only zlib that was missing, but also gccjit (my hack sets both: LIBGCCJIT = -lz -lgccjit)
With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now,
is it?
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 21:41:02 GMT)
Full text and
rfc822 format available.
Message #110 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sat 19 Dec 2020, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Sat, 19 Dec 2020 17:15:02 +0000
>>
>> > I must be missing something, because I don't see strsignal used on
>> > master in the MinGW build at all. Moreover, Gnulib's strsignal.c is
>> > not even in lib/. We call sigdescr_np instead. So I wonder how did
>> > you see that the Gnulib replacement for strsignal is used on master in
>> > the Windows build.
>>
>> Entirely possible that I have misunderstood something from reading
>> sources and grepping (the gnulib gyrations are hard to follow).
>>
>> The emacs source calls strsignal, and something provides it (whether via
>> a macro replacement or a linkable symbol). The only difference I could
>> see was the configure test, as noted above.
>
> The ultimate test is this:
>
> gdb ./emacs.exe
> GNU gdb (GDB) 10.1
> Copyright (C) 2020 Free Software Foundation, Inc.
> ...
> (gdb) rbreak strsignal
>
> On my system, I see just this:
>
> Breakpoint 2 at 0x119b88b: file sysdep.c, line 2617.
> const char *safe_strsignal(int);
Agreed, but emacs has to actually link before I can run it under GDB.
>> I see that src/syssignal.h has a replacement macro:
>>
>> #ifndef HAVE_STRSIGNAL
>> # define strsignal(sig) safe_strsignal (sig)
>> #endif
>>
>> So is the problem that on the native branch the configure test succeeds
>> and sets HAVE_STRSIGNAL, resulting in trying to link the wrong symbol ?
>
> Possibly. The question is, how come the test succeeds? Can you look
> in libjccjit.a with "nm -A" and see if it exports strsignal?
/c/home/ajm/tmp> nm -A /mingw32/lib/libgccjit.dll.a | grep strsignal
C:/msys64/mingw32/lib/libgccjit.dll.a:d025440.o:00000000 I __imp__strsignal
C:/msys64/mingw32/lib/libgccjit.dll.a:d025440.o:00000000 T _strsignal
/c/home/ajm/tmp> nm -A /mingw64/lib/libgccjit.dll.a | grep strsignal
C:/msys64/mingw64/lib/libgccjit.dll.a:d025724.o:0000000000000000 I __imp_strsignal
C:/msys64/mingw64/lib/libgccjit.dll.a:d025724.o:0000000000000000 T strsignal
Yes, it would appear so.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 19 Dec 2020 23:05:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 45303 <at> debbugs.gnu.org (full text, mbox):
The linker issue remains after commit .407fb16583
Also, after adding -lz -lgccjit to $LIBGCCJIT in src/Makefile there's
a segmentation error at make -C src/bootstramp-emacs.exe:
Loading c:/msys64/home/VWinUser0/Downloads/emacs/native-compmake[1]:
*** [Makefile:830: bootstrap-emacs.pdmp] Segmentation fault
make[1]: *** Deleting file 'bootstrap-emacs.pdmp'
make[1]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/src'
make: *** [Makefile:434: src] Error 2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 02:32:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 45303 <at> debbugs.gnu.org (full text, mbox):
By sticking with commit #
3b53a591faed03679382a601b93da7fe6ce3b4af,,
it compiles, but it crashes when Iopen then close an ielm window.
On Sat, Dec 19, 2020 at 5:04 PM Liāu, Kiong-Gē 廖宮毅
<gongyi.liao <at> gmail.com> wrote:
>
> The linker issue remains after commit .407fb16583
>
> Also, after adding -lz -lgccjit to $LIBGCCJIT in src/Makefile there's
> a segmentation error at make -C src/bootstramp-emacs.exe:
>
> Loading c:/msys64/home/VWinUser0/Downloads/emacs/native-compmake[1]:
> *** [Makefile:830: bootstrap-emacs.pdmp] Segmentation fault
> make[1]: *** Deleting file 'bootstrap-emacs.pdmp'
> make[1]: Leaving directory
> '/home/VWinUser0/Downloads/emacs/native-comp/build/src'
> make: *** [Makefile:434: src] Error 2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 08:39:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 45303 <at> debbugs.gnu.org (full text, mbox):
=?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org, _?= Kiong-Gē 廖宮毅
<gongyi.liao <at> gmail.com> writes:
> a segmentation error at make -C src/bootstramp-emacs.exe:
^^^^^
Wow, didn't know aqbout :-)
SCNR, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 09:50:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
That's a typo, should be make -C src/ bootstrap-emacs.exe
On Sun, Dec 20, 2020, 02:38 Michael Albinus <michael.albinus <at> gmx.de> wrote:
> =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org, _?= Kiong-Gē 廖宮毅
> <gongyi.liao <at> gmail.com> writes:
>
> > a segmentation error at make -C src/bootstramp-emacs.exe:
> ^^^^^
> Wow, didn't know aqbout :-)
>
> SCNR, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 11:24:02 GMT)
Full text and
rfc822 format available.
Message #125 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sat 19 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Pal Gloss <pcfeb0009 <at> gmx.com> writes:
>
>> Hi,
>>
>> thank you for the quick fixes
>>
>> I do not understand 3b53a591faed03679382a601b93da7fe6ce3b4af: the way
>
> No you are right, this morning I was a little in a rush and I might have
> failed grepping, hopefully ab985f41db is better.
>
> [...]
>
>> I just checked and these %emacs_dir% are also present in a "normal" emacs
>> 27.1 (installed via msys2/mingw pacman, not self-built).
>>
>>> Right so (unless I'm forgetting something) just the zlib linker error
>>> should be remaining, correct?
>>
>> It was not only zlib that was missing, but also gccjit (my hack sets both: LIBGCCJIT = -lz -lgccjit)
>
> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now,
> is it?
There is one piece missing from that commit: another define around
L379 to replace gcc_jit_type_get_const with fn_gcc_jit_type_get_const.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 16:16:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> But in general, I'd suggest to file a bug report with MSYS2 folks:
> the DLL and the import library shouldn't export strsignal.
Sorry for my previous mail, I raised the issue in the wrong repository so
I closed it and re-opened it in the right (I hope) place:
https://github.com/msys2/MINGW-packages/issues/7484
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 16:24:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Andrea,
Sorry for sending my previous mail to your address only and not to the bug tracker.
I'm not used to debbugs (as you can guess from the many HTML mails I sent, blush).
I wrote
> > I do not understand 3b53a591faed03679382a601b93da7fe6ce3b4af: the way
You answered
> No you are right, this morning I was a little in a rush and I might have
> failed grepping, hopefully ab985f41db is better.
There are still problems related to the usage of Fdirectory_files and
internal_condition_case_5 I think. At least, I get a crash after the
bootstrap is dumped (? see attached build log)
Debugger entered--Lisp error: (wrong-type-argument wholenump t)
> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now, is it?
It is still needed, see my previous mail. But adding -lgccjit allows the build
to proceed but crashes later on.
Can I propose a patch if I have not signed the paperwork?
Thank you for this great new feature.
These are the commands I ran to produce the attached build log:
#+begin_src shell :exports code
(
PROCESSORS_TO_USE="3"
EMACS_VERSION="emacs-native-comp"
cd ../emacs
rm -rf ../build
git restore .
git status
git rev-parse HEAD
gcc --version
./autogen.sh
mkdir -p ../build
cd ../build
../emacs/configure \
--with-xml2 \
--without-pop \
--prefix="/home/cramaph1/$EMACS_VERSION/dest" \
--without-compress-install \
--without-dbus \
--with-nativecomp \
--with-modules 'CFLAGS=-O2 -g3'
# fix linker errors by making sure the correct libraries are added to the linker command
sed -i -e 's/^LIBGCCJIT = *$/LIBGCCJIT = -lz -lgccjit/' src/Makefile
make -j"$PROCESSORS_TO_USE"
make install
) 2>&1 | tee /tmp/emacs-$(git rev-parse HEAD)-lz-lgccjit.log
#+end_src
[emacs-ab985f41db5fdaeada513d28a065332fd8838cf4-lz-lgccjit.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 16:33:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 45303 <at> debbugs.gnu.org (full text, mbox):
For comparison, on linux (Debian Bullseye), we got:
~ $ nm -D /usr/lib/x86_64-linux-gnu/libgccjit.so.0.0.1 | grep strs
U strsignal@@GLIBC_2.2.5
U strspn@@GLIBC_2.2.5
U strstr@@GLIBC_2.2.5
exported from Glibc, not libgccjit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 18:59:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Andy Moreton <andrewjmoreton <at> gmail.com> writes:
> On Sat 19 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> Pal Gloss <pcfeb0009 <at> gmx.com> writes:
>>
>>> Hi,
>>>
>>> thank you for the quick fixes
>>>
>>> I do not understand 3b53a591faed03679382a601b93da7fe6ce3b4af: the way
>>
>> No you are right, this morning I was a little in a rush and I might have
>> failed grepping, hopefully ab985f41db is better.
>>
>> [...]
>>
>>> I just checked and these %emacs_dir% are also present in a "normal" emacs
>>> 27.1 (installed via msys2/mingw pacman, not self-built).
>>>
>>>> Right so (unless I'm forgetting something) just the zlib linker error
>>>> should be remaining, correct?
>>>
>>> It was not only zlib that was missing, but also gccjit (my hack sets both: LIBGCCJIT = -lz -lgccjit)
>>
>> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now,
>> is it?
>
> There is one piece missing from that commit: another define around
> L379 to replace gcc_jit_type_get_const with fn_gcc_jit_type_get_const.
>
> AndyM
Thanks, hope 18ca9ea08a fix it.
Is no easy to write code without being able to test it (read patches are
very welcome).
Thx!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 19:08:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Pal Gloss <pcfeb0009 <at> gmx.com> writes:
> Hi Andrea,
>
> Sorry for sending my previous mail to your address only and not to the bug tracker.
> I'm not used to debbugs (as you can guess from the many HTML mails I sent, blush).
No issue :)
> I wrote
>> > I do not understand 3b53a591faed03679382a601b93da7fe6ce3b4af: the way
> You answered
>> No you are right, this morning I was a little in a rush and I might have
>> failed grepping, hopefully ab985f41db is better.
>
> There are still problems related to the usage of Fdirectory_files and
> internal_condition_case_5 I think. At least, I get a crash after the
> bootstrap is dumped (? see attached build log)
>
> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
Not too surprised, this code is not leveraged since a while :/
>> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now, is it?
>
> It is still needed, see my previous mail. But adding -lgccjit allows the build
> to proceed but crashes later on.
Hopefully this is fixed now by 3bb2fd0c58?
> Can I propose a patch if I have not signed the paperwork?
IIRC there is a cumulative limit of like 10 lines for patches to be
accepted with no assignment.
The right fix for this is to take action *now* and ask maintainers for
your paperworks :) It would be great to have a contributor regularly
compiling this build. Yes I will break it again...
> Thank you for this great new feature.
Thank you for the help.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 19:11:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org, _?= Kiong-Gē 廖宮毅
> <gongyi.liao <at> gmail.com> writes:
>
>> a segmentation error at make -C src/bootstramp-emacs.exe:
> ^^^^^
> Wow, didn't know aqbout :-)
That's one of the easter eggs of the branch :D
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 19:12:02 GMT)
Full text and
rfc822 format available.
Message #146 received at submit <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
[...]
> Thanks, hope 18ca9ea08a fix it.
^^^^^
3bb2fd0c58
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 19:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 19:47:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 45303 <at> debbugs.gnu.org (full text, mbox):
The last commit still has the linker issue, and this time we have
"strsignal" pops up
CCLD temacs.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
comp.o: in function `md5_gz_stream':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:717:
undefined reference to `inflateInit2_'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:734:
undefined reference to `inflate'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:745:
undefined reference to `inflateEnd'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:745:
undefined reference to `inflateEnd'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
process.o: in function `status_message':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/process.c:754:
undefined reference to `strsignal'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
callproc.o: in function `call_process':
C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/callproc.c:916:
undefined reference to `strsignal'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:661: temacs.exe] Error 1
make[1]: Leaving directory
'/home/VWinUser0/Downloads/emacs/native-comp/build/src'
make: *** [Makefile:434: src] Error 2
On Sun, Dec 20, 2020 at 1:10 PM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> > =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org, _?= Kiong-Gē 廖宮毅
> > <gongyi.liao <at> gmail.com> writes:
> >
> >> a segmentation error at make -C src/bootstramp-emacs.exe:
> > ^^^^^
> > Wow, didn't know aqbout :-)
>
> That's one of the easter eggs of the branch :D
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sun, 20 Dec 2020 20:05:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 45303 <at> debbugs.gnu.org (full text, mbox):
=?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org, _?= Kiong-Gē 廖宮毅
<gongyi.liao <at> gmail.com> writes:
> The last commit still has the linker issue, and this time we have
> "strsignal" pops up
Yep that's expected, this commit was just for libgccjit. Tomorrow I'll
rework the zlib dependent code to address that too.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 00:54:01 GMT)
Full text and
rfc822 format available.
Message #158 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sun 20 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> [...]
>
>> Thanks, hope 18ca9ea08a fix it.
> ^^^^^
> 3bb2fd0c58
Thanks Andrea, that problem is fixed. There are still some warnings from
comp.c that indicate other troubles:
C:/emacs/git/emacs/native/src/comp.c: In function 'Fcomp__compile_ctxt_to_file':
C:/emacs/git/emacs/native/src/comp.c:4461:12: warning: unused variable 'oldset' [-Wunused-variable]
4461 | sigset_t oldset;
| ^~~~~~
C:/emacs/git/emacs/native/src/comp.c: In function 'eln_load_path_final_clean_up':
C:/emacs/git/emacs/native/src/comp.c:4626:12: warning: passing argument 7 of 'internal_condition_case_5' from incompatible pointer type [-Wincompatible-pointer-types]
4626 | Qt, return_nil, Qnil);
| ^~~~~~~~~~
| |
| struct Lisp_X * (*)(struct Lisp_X *)
In file included from C:/emacs/git/emacs/native/src/comp.c:23:
C:/emacs/git/emacs/native/src/lisp.h:4161:195: note: expected 'Lisp_Object' {aka 'struct Lisp_X *'} but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
4161 | extern Lisp_Object internal_condition_case_5 (Lisp_Object (*) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
| ^~~~~~~~~~~
In file included from C:/emacs/git/emacs/native/src/lisp.h:944,
from C:/emacs/git/emacs/native/src/comp.c:23:
./globals.h:6980:14: warning: passing argument 8 of 'internal_condition_case_5' from incompatible pointer type [-Wincompatible-pointer-types]
6980 | #define Qnil builtin_lisp_symbol (0)
| ^~~~~~~~~~~~~~~~~~~~~~~
| |
| Lisp_Object {aka struct Lisp_X *}
C:/emacs/git/emacs/native/src/comp.c:4626:24: note: in expansion of macro 'Qnil'
4626 | Qt, return_nil, Qnil);
| ^~~~
In file included from C:/emacs/git/emacs/native/src/comp.c:23:
C:/emacs/git/emacs/native/src/lisp.h:4161:208: note: expected 'struct Lisp_X * (*)(struct Lisp_X *)' but argument is of type 'Lisp_Object' {aka 'struct Lisp_X *'}
4161 | extern Lisp_Object internal_condition_case_5 (Lisp_Object (*) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The internal_condition_case_5 usage looks like the last two arguments
might be swapped.
The return_nil function is also declared as a nested function: that is a
gcc extension, so it is more portable to define it as an ordinary static
function.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 08:03:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Andy Moreton <andrewjmoreton <at> gmail.com> writes:
> On Sun 20 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>>
>> [...]
>>
>>> Thanks, hope 18ca9ea08a fix it.
>> ^^^^^
>> 3bb2fd0c58
>
> Thanks Andrea, that problem is fixed. There are still some warnings from
> comp.c that indicate other troubles:
>
> C:/emacs/git/emacs/native/src/comp.c: In function 'Fcomp__compile_ctxt_to_file':
> C:/emacs/git/emacs/native/src/comp.c:4461:12: warning: unused variable 'oldset' [-Wunused-variable]
> 4461 | sigset_t oldset;
> | ^~~~~~
> C:/emacs/git/emacs/native/src/comp.c: In function 'eln_load_path_final_clean_up':
> C:/emacs/git/emacs/native/src/comp.c:4626:12: warning: passing argument 7 of 'internal_condition_case_5' from incompatible pointer type [-Wincompatible-pointer-types]
> 4626 | Qt, return_nil, Qnil);
> | ^~~~~~~~~~
> | |
> | struct Lisp_X * (*)(struct Lisp_X *)
> In file included from C:/emacs/git/emacs/native/src/comp.c:23:
> C:/emacs/git/emacs/native/src/lisp.h:4161:195: note: expected 'Lisp_Object' {aka 'struct Lisp_X *'} but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
> 4161 | extern Lisp_Object internal_condition_case_5 (Lisp_Object (*)
> (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object),
> Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object, Lisp_Object (*) (Lisp_Object));
> | ^~~~~~~~~~~
> In file included from C:/emacs/git/emacs/native/src/lisp.h:944,
> from C:/emacs/git/emacs/native/src/comp.c:23:
> ./globals.h:6980:14: warning: passing argument 8 of 'internal_condition_case_5' from incompatible pointer type [-Wincompatible-pointer-types]
> 6980 | #define Qnil builtin_lisp_symbol (0)
> | ^~~~~~~~~~~~~~~~~~~~~~~
> | |
> | Lisp_Object {aka struct Lisp_X *}
> C:/emacs/git/emacs/native/src/comp.c:4626:24: note: in expansion of macro 'Qnil'
> 4626 | Qt, return_nil, Qnil);
> | ^~~~
> In file included from C:/emacs/git/emacs/native/src/comp.c:23:
> C:/emacs/git/emacs/native/src/lisp.h:4161:208: note: expected 'struct Lisp_X * (*)(struct Lisp_X *)' but argument is of type 'Lisp_Object' {aka 'struct Lisp_X *'}
> 4161 | extern Lisp_Object internal_condition_case_5 (Lisp_Object (*)
> (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object),
> Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object, Lisp_Object (*) (Lisp_Object));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> The internal_condition_case_5 usage looks like the last two arguments
> might be swapped.
Right, f4153cac3e and 2526032ea9 should fix those two issues.
IIUC compilation-wise we are left only with the zlib issue now.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 08:10:02 GMT)
Full text and
rfc822 format available.
Message #164 received at submit <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
[...]
> IIUC compilation-wise we are left only with the zlib issue now.
Ah yeah and the `strsignal' issue too, but ATM that's not clear if this
is something we want to workaround in our code or not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 08:10:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 09:49:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 45303 <at> debbugs.gnu.org, gongyi.liao <at> gmail.com,
>> =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
>> Date: Fri, 18 Dec 2020 16:37:31 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Date: Fri, 18 Dec 2020 13:28:20 +0000
>> >> Cc: gongyi.liao <at> gmail.com, =?UTF-8?Q?Li=C4=81u <at> debbugs.gnu.org
>> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
>> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> >>
>> >> >> CCLD temacs.exe
>> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> >> >> comp.o: in function `md5_gz_stream':
>> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:713:
>> >> >> undefined reference to `inflateInit2_'
>> >> >> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> >> >> C:\msys64\home\VWinUser0\Downloads\emacs\native-comp\build\src/../../src/src/comp.c:730:
>> >> >> undefined reference to `inflate'
>> >> >
>> >> > That's curious, looks you've not zlib but from the config.log you do...
>> >>
>> >> I really would like to understand what's going on here.
>> >>
>> >> We check in configure for zlib presence, actually this is also require
>> >> by --with-nativecomp but somehow the linker fails to find it.
>> >
>> > Why does the native-comp branch require zlib in comp.c? what does it
>> > do with zlib?
>>
>> We hash the content of the lisp source files to obtain the correspondent
>> eln name in the eln-cache.
>>
>> This machinery has to work since early bootstrap (and has to be fast
>> since is executed at each file load), so is directly done from comp.c.
>>
>> When Emacs is installed the el files are compressed and so before
>> hashing them we have to decompress therefore we use zlib.
>
> Thanks for the explanations.
>
>> > On master, zlib is an optional library, and when some Emacs command is
>> > invoked that needs it, on MS-Windows we load the zlib DLL at run time
>> > when requested. See init_zlib_functions in decompress.c. This is
>> > unlike on Posix systems, where Emacs is linked with zlib at link time.
>> > Does this explain what is going on?
>>
>> I see, we should probably have comp.c use the necessary DEF_DLL_FN bloat
>> or have these functions wrapped in decompress.c.
>
> I think it's better to use functions in decompress.c or add whatever
> you need there, and have the new functions use the same paradigm,
> which on Windows loads the DLL the first time it is needed.
Hi Eli,
so I did, with 5b10a0324d I moved 'md5_gz_stream' to decompress.c,
before running it we load zlib if necessary.
Hopefully this solves this part of the issue.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 10:11:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> There are still problems related to the usage of Fdirectory_files and
> internal_condition_case_5 I think. At least, I get a crash after the
> bootstrap is dumped (? see attached build log)
>
> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
Despite 2526032ea954671aa48a6ad6d924df2941a8364a, this error still happens:
Qt and Qnil should be swapped (see sed script at the bottom of the mail
inside my build commands or the git diff in the build log).
> >> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now, is it?
> >
> > It is still needed, see my previous mail. But adding -lgccjit allows the build
> > to proceed but crashes later on.
>
> Hopefully this is fixed now by 3bb2fd0c58?
Not quite: -lgccjit was still needed for strsignal. Note that the strsignal is a
double problem:
1. Because configure can link the test program with the call to strsignal because
libgccjit exports it (though Eli argues it shouldn't and I've reported an issue
to the mingw64-packages repository), no special provision is made to include a
header defining the function. Hence, during compilation, there are several
warnings that gcc assumes that strsignal returns an int and has to cast it to
const char*.
2. Because -lgccjit is not added to LIBGCCJIT (it is supposed to be loaded
dynamically, if I understood it right), strsignal is not found at linking time.
So, even when hacking the LIBGCCJIT to contain -lgccjit in src/Makefile, I'm just
allowing the linking to succeed, but probably risk a crash because the linked
function strsignal does not match the implicit definition assumed by gcc (?).
In the end, I've applied (see sed script at the bottom of the mail
inside my build commands or the git diff in the build log) AndyM's suggestion
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45303#83) to nt/mingw-cfg.site.
After this change, there are no nativecomp related warnings nor errors during
the build if I still include -lz in LIBGCCJIT in src/Makefile. Regarding my
change to nt/mingw-cfg.sites, be aware that I know even less about the
configuration process than AndyM (I would not have known about
nt/mingw-cfg.sites) and he says:
> Adding "ac_cv_func_strsignal=no" in nt/mingw-cfg.site appears to
> suppress this problem, but I don't know if that is the right fix.
TLDR for 2526032ea954671aa48a6ad6d924df2941a8364a:
- swap Qt and Qnil in src/comp.c
- fix the strsignal problem, then only -lz is needed
Kind regards,
--
Pal Gloss
#+begin_src shell :exports code
(
PROCESSORS_TO_USE="3"
EMACS_VERSION="emacs-native-comp"
cd ../emacs
rm -rf ../build
gcc --version
git restore .
sed -i -e '${ a # force strsignal from gnulib to be used (cf https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45303#83)
a ac_cv_func_strsignal=no
}' \
nt/mingw-cfg.site
sed -i -e '/^[^a-z]* *Qt, Qnil, return_nil);$/ {
s;.*;/* Fix argument order to avoid "error (wrong-type-argument wholenump t)" */;
a Qnil, Qt, return_nil);
}' \
src/comp.c
echo "Starting point is $(git rev-parse HEAD) with the following changes:"
git status
git diff
./autogen.sh
mkdir -p ../build
cd ../build
../emacs/configure \
--with-xml2 \
--without-pop \
--prefix="/home/cramaph1/$EMACS_VERSION/dest" \
--without-compress-install \
--without-dbus \
--with-nativecomp \
--with-modules 'CFLAGS=-O2 -g3'
# fix
# (1) linker errors by tuning LIBGCCJIT making sure the correct libraries are added to the linker command
sed -i -e 's/^LIBGCCJIT = *$/LIBGCCJIT = -lz/' \
src/Makefile
make -j"$PROCESSORS_TO_USE"
make install
) 2>&1 | tee /tmp/emacs-$(git rev-parse HEAD)-patch_mingw.site-patch_comp.c-lz.log
[emacs-2526032ea954671aa48a6ad6d924df2941a8364a-patch_mingw.site-patch_comp.c-lz.log (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 12:09:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Pal Gloss <pcfeb0009 <at> gmx.com> writes:
>> There are still problems related to the usage of Fdirectory_files and
>> internal_condition_case_5 I think. At least, I get a crash after the
>> bootstrap is dumped (? see attached build log)
>>
>> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
>
> Despite 2526032ea954671aa48a6ad6d924df2941a8364a, this error still happens:
> Qt and Qnil should be swapped (see sed script at the bottom of the mail
> inside my build commands or the git diff in the build log).
Hi Pal thanks for trying.
I don't like to run or decript scripts, I like to review and apply
patches from contributors, why don't you submit one for this? :)
>> >> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now, is it?
>> >
>> > It is still needed, see my previous mail. But adding -lgccjit allows the build
>> > to proceed but crashes later on.
>>
>> Hopefully this is fixed now by 3bb2fd0c58?
>
> Not quite: -lgccjit was still needed for strsignal. Note that the strsignal is a
> double problem:
> 1. Because configure can link the test program with the call to strsignal because
> libgccjit exports it (though Eli argues it shouldn't and I've reported an issue
> to the mingw64-packages repository), no special provision is made to include a
> header defining the function. Hence, during compilation, there are several
> warnings that gcc assumes that strsignal returns an int and has to cast it to
> const char*.
Eli is right, mingw64 should fix this.
We might provide the prototype ourselfs but I don't think is a good
idea. I think is probably better not to define HAVE_STRSIGNAL depending
on libgccjit.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 16:22:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: Pal Gloss <pcfeb0009 <at> gmx.com>
> Date: Mon, 21 Dec 2020 11:10:15 +0100
>
> Not quite: -lgccjit was still needed for strsignal. Note that the strsignal is a
> double problem:
> 1. Because configure can link the test program with the call to strsignal because
> libgccjit exports it (though Eli argues it shouldn't and I've reported an issue
> to the mingw64-packages repository), no special provision is made to include a
> header defining the function. Hence, during compilation, there are several
> warnings that gcc assumes that strsignal returns an int and has to cast it to
> const char*.
> 2. Because -lgccjit is not added to LIBGCCJIT (it is supposed to be loaded
> dynamically, if I understood it right), strsignal is not found at linking time.
>
> So, even when hacking the LIBGCCJIT to contain -lgccjit in src/Makefile, I'm just
> allowing the linking to succeed, but probably risk a crash because the linked
> function strsignal does not match the implicit definition assumed by gcc (?).
>
> In the end, I've applied (see sed script at the bottom of the mail
> inside my build commands or the git diff in the build log) AndyM's suggestion
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45303#83) to nt/mingw-cfg.site.
I think this is the correct solution in this case. No matter what the
MSYS2 folks do with the original problem, MinGW doesn't have strsignal
and won't have it any time soon, so telling this to configure in
mingw.site cannot possibly do any harm.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 17:42:01 GMT)
Full text and
rfc822 format available.
Message #182 received at submit <at> debbugs.gnu.org (full text, mbox):
On Mon 21 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> [...]
>
>> IIUC compilation-wise we are left only with the zlib issue now.
>
> Ah yeah and the `strsignal' issue too, but ATM that's not clear if this
> is something we want to workaround in our code or not.
Yes. If the distro libgccjit packages are updated to avoid exporting
strsignal then this problem should go away: otherwise, a workaround is
to add ac_cv_func_strsignal=no in nt/mingw-cfg.site.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 18:04:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Following Pal's script in #173, I can compile emacs native-comp
without out problems, however, when I try to run native-compile
function at a IELM prompt, I got the following error message:
comp--native-compile: Native compiler error: (lambda (arg0 &optional
arg1) (let ((f #'delete-char)) (funcall f arg0 arg1))), ""Invalid face
attribute :background nil
Not sure if it's caused by some patches to comp.c
Thanks,
Kiong-Ge.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Mon, 21 Dec 2020 22:48:02 GMT)
Full text and
rfc822 format available.
Message #188 received at submit <at> debbugs.gnu.org (full text, mbox):
On Mon 21 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Pal Gloss <pcfeb0009 <at> gmx.com> writes:
>
>>> There are still problems related to the usage of Fdirectory_files and
>>> internal_condition_case_5 I think. At least, I get a crash after the
>>> bootstrap is dumped (? see attached build log)
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
>>
>> Despite 2526032ea954671aa48a6ad6d924df2941a8364a, this error still happens:
>> Qt and Qnil should be swapped (see sed script at the bottom of the mail
>> inside my build commands or the git diff in the build log).
>
> Hi Pal thanks for trying.
>
> I don't like to run or decript scripts, I like to review and apply
> patches from contributors, why don't you submit one for this? :)
The fix needed here is another tweak to eln_load_path_final_clean_up:
the arguments for internal_condition_case_5 should end "Qnil, Qt,
return_nil". After fixing that then a bootstrap build completes without
crashes.
Other issues noted when running the uninstalled emacs from build dir:
a) The ELN compile step is very slow during bootstrap.
b) The built emacs will run uninstalled (i.e. directly from the build
tree), but is almost unusable as the async ELN compile make emacs
very unresponsive to input.
c) The .eln files for a few core .el files are built in:
<builddir>/native-lisp/<version>-<target>-<hash>/*.eln
The async compile puts .eln files in:
$HOME/.emacs.d/eln-cache/<version>-<target>-<hash>/*.eln
Q1: Why are the compiled files not added to builddir/lisp-native ?
Q2: Why are the directory and filenames so long ?
Q3: Why are the directory names different ?
This needs a heirarchy of files named after a hash of their content.
This problem has been solved by git, mercurial etc, and it would be
better to use a similar layout, and learn lessons from those tools
for how to do so efficiently.
Q4: Why are the lisp files not *all* precompiled as part of the build ?
Q5: What can be done to improve the slow compile time ?
Q6: Why are the built files so large ?
For example:
47609 abbrev.el
40298 abbrev.elc
174799 abbrev-2af30c9ac0795d54ce43b6286aa259ff-a03852565cd14ed2eaa6f4159b530c2e.eln
Thanks for working on this,
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 08:48:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Andy Moreton <andrewjmoreton <at> gmail.com> writes:
> On Mon 21 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> Pal Gloss <pcfeb0009 <at> gmx.com> writes:
>>
>>>> There are still problems related to the usage of Fdirectory_files and
>>>> internal_condition_case_5 I think. At least, I get a crash after the
>>>> bootstrap is dumped (? see attached build log)
>>>>
>>>> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
>>>
>>> Despite 2526032ea954671aa48a6ad6d924df2941a8364a, this error still happens:
>>> Qt and Qnil should be swapped (see sed script at the bottom of the mail
>>> inside my build commands or the git diff in the build log).
>>
>> Hi Pal thanks for trying.
>>
>> I don't like to run or decript scripts, I like to review and apply
>> patches from contributors, why don't you submit one for this? :)
>
> The fix needed here is another tweak to eln_load_path_final_clean_up:
> the arguments for internal_condition_case_5 should end "Qnil, Qt,
> return_nil". After fixing that then a bootstrap build completes without
> crashes.
I'm sorry this week I'm rather busy progressing on new features plus I
cannot test Windows patches and this makes it very time consuming.
As I've said more then once on this thread: patches are welcome.
> Other issues noted when running the uninstalled emacs from build dir:
I think these are off topic for this thread but quickly:
> a) The ELN compile step is very slow during bootstrap.
On my machine make bootstrap is ~2.5x slower than vanilla build.
> b) The built emacs will run uninstalled (i.e. directly from the build
> tree), but is almost unusable as the async ELN compile make emacs
> very unresponsive to input.
You can customize `comp-async-jobs-number'.
<http://akrl.sdf.org/gccemacs.html#org73a9089>
The default works well on most systems but probably is not optimal for
your machine.
> c) The .eln files for a few core .el files are built in:
> <builddir>/native-lisp/<version>-<target>-<hash>/*.eln
>
> The async compile puts .eln files in:
> $HOME/.emacs.d/eln-cache/<version>-<target>-<hash>/*.eln
>
> Q1: Why are the compiled files not added to builddir/lisp-native ?
> Q2: Why are the directory and filenames so long ?
> Q3: Why are the directory names different ?
<https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg02186.html>
<http://akrl.sdf.org/gccemacs.html#org71a8de5>
> This needs a heirarchy of files named after a hash of their content.
> This problem has been solved by git, mercurial etc, and it would be
> better to use a similar layout, and learn lessons from those tools
> for how to do so efficiently.
Are you asking at the same time how the current system works and
suggesting how it should?
> Q4: Why are the lisp files not *all* precompiled as part of the
> build ?
make bootstrap NATIVE_FULL_AOT=1
<http://akrl.sdf.org/gccemacs.html#orgdb45946>
<http://akrl.sdf.org/gccemacs.html#orga0c267d>
> Q5: What can be done to improve the slow compile time ?
I've never had the time to optimize the Lisp side of the compiler, last
week I did some profiling and made an idea on where and how to take
action. I'll be on that in the new year, the current one has been
mostly on debug and integration.
> Q6: Why are the built files so large ?
If you want a more compact representation of the code byte-code is
probably a better format than native code.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 15:48:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Andrea and Pal,
the attached file is the patch applicable to snapshot after commit [9676e4d7766cea647a4e2b9e27fad97479b418de](http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=feature/native-comp&id=9676e4d7766cea647a4e2b9e27fad97479b418de)
Kiong-Ge.
[Message part 2 (text/html, inline)]
[patch_for_9676e4d7766cea647a4e2b9e27fad97479b418de.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 19:16:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 45303 <at> debbugs.gnu.org (full text, mbox):
"gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
> Hi Andrea and Pal,
>
> the attached file is the patch applicable to snapshot after commit
> 9676e4d7766cea647a4e2b9e27fad97479b418de
>
> Kiong-Ge.
Hi Kiong-Ge,
thanks for taking the time.
Do you have copyright assignment or this goes under the
copyright-paperwork-exempt?
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 19:42:01 GMT)
Full text and
rfc822 format available.
Message #200 received at submit <at> debbugs.gnu.org (full text, mbox):
On Tue 22 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> Andy Moreton <andrewjmoreton <at> gmail.com> writes:
[snipped]
>> Other issues noted when running the uninstalled emacs from build dir:
>
> I think these are off topic for this thread but quickly:
Agreed, but thanks for giving links to relevant info. I'll read up some
more and ask any further questions on emacs-devel.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 19:49:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Hi Andrea and Pal,
I haven't provide any copyright assignment and I am not sure copyright-paperwork exempt is applicable to this patch, as this patch is derived from the script provided by Pal.
I would like to ask Pal if it's okay to Pal that I provide the copyright assignment. If Pal want to provide the copyright assignment that will be great, if Pal doesn't want to provide copyright assignment and grant me to do so, I am glad to provide copyright assignment if needed.
Thanks,
Kiong-Ge.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, December 22, 2020 1:15 PM, Andrea Corallo <akrl <at> sdf.org> wrote:
> %22gliao.tw <at> pm.me">--protonSignature--"gliao.tw <at> pm.me" gliao.tw <at> pm.me writes:
>
> > Hi Andrea and Pal,
> > the attached file is the patch applicable to snapshot after commit
> > 9676e4d7766cea647a4e2b9e27fad97479b418de
> > Kiong-Ge.
>
> Hi Kiong-Ge,
>
> thanks for taking the time.
>
> Do you have copyright assignment or this goes under the
> copyright-paperwork-exempt?
>
> Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 19:51:02 GMT)
Full text and
rfc822 format available.
Message #206 received at submit <at> debbugs.gnu.org (full text, mbox):
On Tue 22 Dec 2020, gliao.tw--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Hi Andrea and Pal,
>
> the attached file is the patch applicable to snapshot after commit
> [9676e4d7766cea647a4e2b9e27fad97479b418de](http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=feature/native-comp&id=9676e4d7766cea647a4e2b9e27fad97479b418de)
>
> Kiong-Ge.
> diff -ruN src-orig/nt/mingw-cfg.site src/nt/mingw-cfg.site
> --- src-orig/nt/mingw-cfg.site 2020-12-22 15:36:18.429108443 +0000
> +++ src/nt/mingw-cfg.site 2020-12-22 15:37:18.099953457 +0000
> @@ -156,3 +156,5 @@
> # We don't want to build Emacs so it depends on bcrypt.dll, since then
> # it will refuse to start on systems where that DLL is absent.
> gl_cv_lib_assume_bcrypt=no
> +# force strsignal from gnulib to be used (cf https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45303#83)
> +ac_cv_func_strsignal=no
This comment is not quite right: Eli pointed out that emacs does not
use the gnulib replacement function on Windows. Adding this line to
mingw.site ensures that HAVE_STRSIGNAL is not defined in config.h, so
the strsignal macro in src/syssignal.h gets used.
AndyM
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 20:10:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 45303 <at> debbugs.gnu.org (full text, mbox):
"gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
> Hi Andrea and Pal,
>
> I haven't provide any copyright assignment and I am not sure
> copyright-paperwork exempt is applicable to this patch, as this patch
> is derived from the script provided by Pal.
Hi Kiong-Ge,
the copyright assignment is between you and the fsf, you can see the
CONTRIBUTE file under 'Getting involved with development' and 'Commit
messages'.
This change is sufficently small and simple to go in with the
paperwork-exempt.
I added a changelog for you tweaked one comment and pushed it as
433ae7b0a5.
Are we fine now with the compilation process?
Regards
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 20:16:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Andrea,
The native-comp branch compiles smoothly with generated executable working flawlessly under my Msys2 environment on Windows 10.
I don't have anything to report now, if no objection from other people, I think we can close this bug.
Kiong-Ge.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, December 22, 2020 2:09 PM, Andrea Corallo <akrl <at> sdf.org> wrote:
> %22gliao.tw <at> pm.me">--protonSignature--"gliao.tw <at> pm.me" gliao.tw <at> pm.me writes:
>
> > Hi Andrea and Pal,
> > I haven't provide any copyright assignment and I am not sure
> > copyright-paperwork exempt is applicable to this patch, as this patch
> > is derived from the script provided by Pal.
>
> Hi Kiong-Ge,
>
> the copyright assignment is between you and the fsf, you can see the
> CONTRIBUTE file under 'Getting involved with development' and 'Commit
> messages'.
>
> This change is sufficently small and simple to go in with the
> paperwork-exempt.
>
> I added a changelog for you tweaked one comment and pushed it as
> 433ae7b0a5.
>
> Are we fine now with the compilation process?
>
> Regards
>
> Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 20:22:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 45303 <at> debbugs.gnu.org (full text, mbox):
"gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
> Andrea,
>
> The native-comp branch compiles smoothly with generated executable working flawlessly under my Msys2 environment on Windows 10.
>
> I don't have anything to report now, if no objection from other people, I think we can close this bug.
Sounds like music to my ears :)
Closing, we can always reopen in case.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Tue, 22 Dec 2020 20:40:01 GMT)
Full text and
rfc822 format available.
Message #218 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Dec 2020 20:21:54 +0000
> Cc: "pcfeb0009 <at> gmx.com" <pcfeb0009 <at> gmx.com>,
> "45303-done <at> debbugs.gnu.org" <45303 <at> debbugs.gnu.org>
> From: Andrea Corallo via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> "gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
>
> > Andrea,
> >
> > The native-comp branch compiles smoothly with generated executable working flawlessly under my Msys2 environment on Windows 10.
> >
> > I don't have anything to report now, if no objection from other people, I think we can close this bug.
>
> Sounds like music to my ears :)
Thanks for a job well done, Andrea.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Wed, 23 Dec 2020 07:03:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 45303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Tue, 22 Dec 2020 20:21:54 +0000
>> Cc: "pcfeb0009 <at> gmx.com" <pcfeb0009 <at> gmx.com>,
>> "45303-done <at> debbugs.gnu.org" <45303 <at> debbugs.gnu.org>
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> "gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
>>
>> > Andrea,
>> >
>> > The native-comp branch compiles smoothly with generated executable working flawlessly under my Msys2 environment on Windows 10.
>> >
>> > I don't have anything to report now, if no objection from other people, I think we can close this bug.
>>
>> Sounds like music to my ears :)
>
> Thanks for a job well done, Andrea.
Was good team work, thank you & all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 26 Dec 2020 14:25:01 GMT)
Full text and
rfc822 format available.
Message #224 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: edouard debry <edouard.debry <at> gmail.com>
> Date: Sat, 26 Dec 2020 15:02:54 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, gliao.tw <at> pm.me, pcfeb0009 <at> gmx.com, 45303 <at> debbugs.gnu.org
>
> and added the absolute path of "/mingw64/bin" to the emacs exec-path.
What does this mean, exactly? IOW, how did you add this directory to
exec-path, and why did you need to do it?
First, "/mingw64/bin" is not a valid Windows absolute file name, since
it lacks the drive letter.
And second, Emacs's startup code expects the directories where Emacs
should look for programs to be mentioned in the system-wide PATH
variable. If your PATH doesn't include /mingw64/bin, then you should
add it (assuming that there are program files there that Emacs is
supposed to find and use).
> Outside of mingw64, If I just click on bin/emacs.exe I get a console message :
>
> Warning: arch-dependent data dir '%emacs_dir%/libexec/emacs/28.0.50/x86_64-w64-mingw32/': No such
> file or directory
>
> and an emacs abort dialog.
>
> If I launch emacs on the command line from within a mingw64 shell, it runs well.
Is this specific to the native-comp branch, or does it also happen if
you build and install the master branch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 26 Dec 2020 15:13:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 45303 <at> debbugs.gnu.org (full text, mbox):
> From: edouard debry <edouard.debry <at> gmail.com>
> Date: Sat, 26 Dec 2020 15:58:30 +0100
> Cc: Andrea Corallo <akrl <at> sdf.org>, gliao.tw <at> pm.me, pcfeb0009 <at> gmx.com, 45303 <at> debbugs.gnu.org
>
> However, you were right. Adding :
> SET PATH=D:\xxxx\Documents\utils\msys64\mingw64\bin;%PATH%
> in the batch file ahead of emacs invocation makes it work as normal.
OK.
> Are there some other paths from msys or mingw I should add for emacs startup ?
No, I don't think so.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 26 Dec 2020 16:16:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I was able to compile and install.
However, I cannot launch emacs outside of mingw64.
I installed emacs-nativecomp outside of mingw64 in order not to mess with
the mingw emacs package.
I copied libgmp*dll in the installdir/bin and added the absolute path of
"/mingw64/bin" to the emacs exec-path.
Outside of mingw64, If I just click on bin/emacs.exe I get a console
message :
Warning: arch-dependent data dir
'%emacs_dir%/libexec/emacs/28.0.50/x86_64-w64-mingw32/': No such file or
directory
and an emacs abort dialog.
If I launch emacs on the command line from within a mingw64 shell, it runs
well. But it is not desirable because window
environment variables like %VAR% are not expanded correctly.
I can launch the mingw64 emacs package from outside mingw without this
problem.
So, most probably, I must have missed something during the install.
Do you also have this issue ?
Regards
Le mer. 23 déc. 2020 à 08:03, Andrea Corallo via Bug reports for GNU Emacs,
the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> a écrit :
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Tue, 22 Dec 2020 20:21:54 +0000
> >> Cc: "pcfeb0009 <at> gmx.com" <pcfeb0009 <at> gmx.com>,
> >> "45303-done <at> debbugs.gnu.org" <45303 <at> debbugs.gnu.org>
> >> From: Andrea Corallo via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> "gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
> >>
> >> > Andrea,
> >> >
> >> > The native-comp branch compiles smoothly with generated executable
> working flawlessly under my Msys2 environment on Windows 10.
> >> >
> >> > I don't have anything to report now, if no objection from other
> people, I think we can close this bug.
> >>
> >> Sounds like music to my ears :)
> >
> > Thanks for a job well done, Andrea.
>
> Was good team work, thank you & all.
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Sat, 26 Dec 2020 16:16:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 45303 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Within emacs I do this :
(add-to-list 'exec-path "D:/xxxx/Documents/utils/msys64/mingw64/bin")
However, you were right. Adding :
SET PATH=D:\xxxx\Documents\utils\msys64\mingw64\bin;%PATH%
in the batch file ahead of emacs invocation makes it work as normal.
Are there some other paths from msys or mingw I should add for emacs
startup ?
Regards
Le sam. 26 déc. 2020 à 15:24, Eli Zaretskii <eliz <at> gnu.org> a écrit :
> > From: edouard debry <edouard.debry <at> gmail.com>
> > Date: Sat, 26 Dec 2020 15:02:54 +0100
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, gliao.tw <at> pm.me, pcfeb0009 <at> gmx.com,
> 45303 <at> debbugs.gnu.org
> >
> > and added the absolute path of "/mingw64/bin" to the emacs exec-path.
>
> What does this mean, exactly? IOW, how did you add this directory to
> exec-path, and why did you need to do it?
>
> First, "/mingw64/bin" is not a valid Windows absolute file name, since
> it lacks the drive letter.
>
> And second, Emacs's startup code expects the directories where Emacs
> should look for programs to be mentioned in the system-wide PATH
> variable. If your PATH doesn't include /mingw64/bin, then you should
> add it (assuming that there are program files there that Emacs is
> supposed to find and use).
>
> > Outside of mingw64, If I just click on bin/emacs.exe I get a console
> message :
> >
> > Warning: arch-dependent data dir
> '%emacs_dir%/libexec/emacs/28.0.50/x86_64-w64-mingw32/': No such
> > file or directory
> >
> > and an emacs abort dialog.
> >
> > If I launch emacs on the command line from within a mingw64 shell, it
> runs well.
>
> Is this specific to the native-comp branch, or does it also happen if
> you build and install the master branch?
>
[Message part 2 (text/html, inline)]
Reply sent
to
Andrea Corallo <akrl <at> sdf.org>:
You have taken responsibility.
(Wed, 06 Jan 2021 20:38:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Liāu, Kiong-Gē 廖宮毅 <gongyi.liao <at> gmail.com>:
bug acknowledged by developer.
(Wed, 06 Jan 2021 20:38:02 GMT)
Full text and
rfc822 format available.
Message #238 received at 45303-done <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> "gliao.tw <at> pm.me" <gliao.tw <at> pm.me> writes:
>
>> Andrea,
>>
>> The native-comp branch compiles smoothly with generated executable working flawlessly under my Msys2 environment on Windows 10.
>>
>> I don't have anything to report now, if no objection from other people, I think we can close this bug.
>
> Sounds like music to my ears :)
>
> Closing, we can always reopen in case.
Ops, I failed closing this. Doing it now.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#45303; Package
emacs.
(Wed, 06 Jan 2021 20:39:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 04 Feb 2021 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.