GNU bug report logs - #45303
28.0.50; [feature/native-comp] comp.c compilation error on Windows 10

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 45303 <at> debbugs.gnu.org
Subject: bug#45303: #45303 [feature/native-comp] building error on Windows
Date: Sat, 19 Dec 2020 19:37:49 +0200

> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.