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: Pal Gloss <pcfeb0009 <at> gmx.com>
Cc: 45303 <at> debbugs.gnu.org
Subject: bug#45303: #45303 [feature/native-comp] building error on Windows
Date: Mon, 21 Dec 2020 18:21:28 +0200

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

Previous Next

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