bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Richard Copley]

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

 Linking auxiliary executables fails with undefined references to
(FORTIFY_SOURCE?) functions  __memcpy_chk and __memmove_chk. This is
apparently caused by some change in MSYS2, because previously buildable
commits now fail. Transcript below.

+ make V=1 -k
make -C nt all
make[1]: Entering directory '/c/projects/emacs/nt'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/projects/emacs/nt'
make -C lib all
make[1]: Entering directory '/c/projects/emacs/lib'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/projects/emacs/lib'
make -C lib-src all
make[1]: Entering directory '/c/projects/emacs/lib-src'
gcc  -mtune=generic  -fno-common -W[...]  -I. -I../src -I../lib -I.
-I./../src -I./../lib   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/projects/emacs/nt/inc -O2 emacsclient.c \
   ntlib.o ../lib/libgnu.a  \
   -lwsock32  -lcomctl32 -o emacsclient.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\buster\AppData\Local\Temp\ccVJXdYZ.o:emacsclient.c:(.text+0xb4d):
undefined reference to `__memmove_chk'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:395: emacsclient.exe] Error 1
gcc  -mtune=generic  -fno-common -W[...]  -I. -I../src -I../lib -I.
-I./../src -I./../lib   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/projects/emacs/nt/inc -O2 emacsclient.res -mwindows emacsclient.c \
   ../lib/libgnu.a  \
   -lwsock32  -lcomctl32 -o emacsclientw.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\buster\AppData\Local\Temp\ccSZs6xf.o:emacsclient.c:(.text+0xb4d):
undefined reference to `__memmove_chk'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:400: emacsclientw.exe] Error 1
gcc  -mtune=generic  -fno-common -W[...]  -I. -I../src -I../lib -I.
-I./../src -I./../lib   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/projects/emacs/nt/inc -O2 make-docfile.c ntlib.o ../lib/libgnu.a  -o
make-docfile.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\buster\AppData\Local\Temp\ccHhbMkg.o:make-docfile.c:(.text+0x166a):
undefined reference to `__memcpy_chk'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:382: make-docfile.exe] Error 1
make[1]: Target 'all' not remade because of errors.
make[1]: Leaving directory '/c/projects/emacs/lib-src'
make: *** [Makefile:411: lib-src] Error 2
make info-real info-dir
make[1]: Entering directory '/c/projects/emacs'
make -C doc/lispref info
make[2]: Entering directory '/c/projects/emacs/doc/lispref'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/lispref'
make -C doc/lispintro info
make[2]: Entering directory '/c/projects/emacs/doc/lispintro'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/lispintro'
make -C doc/emacs info
make[2]: Entering directory '/c/projects/emacs/doc/emacs'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/emacs'
make -C doc/misc info
make[2]: Entering directory '/c/projects/emacs/doc/misc'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/misc'
make[1]: Nothing to be done for 'info-dir'.
make[1]: Leaving directory '/c/projects/emacs'
make: Target 'all' not remade because of errors.

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

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 21 Oct 2019 13:28:29 +0100
> 
> Linking auxiliary executables fails with undefined references to (FORTIFY_SOURCE?) functions 
> __memcpy_chk and __memmove_chk. This is apparently caused by some change in MSYS2, because
> previously buildable commits now fail. Transcript below.

Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
adding that, e.g. by

  make LIBS_SYSTEM=-lssp

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Richard Copley]

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

On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Richard Copley <rcopley@gmail.com>
> > Date: Mon, 21 Oct 2019 13:28:29 +0100
> >
> > Linking auxiliary executables fails with undefined references to
> (FORTIFY_SOURCE?) functions
> > __memcpy_chk and __memmove_chk. This is apparently caused by some change
> in MSYS2, because
> > previously buildable commits now fail. Transcript below.
>
> Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
> adding that, e.g. by
>
>   make LIBS_SYSTEM=-lssp
>

Yes, that works.

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

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 21 Oct 2019 14:17:36 +0100
> Cc: 37852@debbugs.gnu.org
> 
> On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > From: Richard Copley <rcopley@gmail.com>
>  > Date: Mon, 21 Oct 2019 13:28:29 +0100
>  > 
>  > Linking auxiliary executables fails with undefined references to (FORTIFY_SOURCE?) functions 
>  > __memcpy_chk and __memmove_chk. This is apparently caused by some change in MSYS2,
>  because
>  > previously buildable commits now fail. Transcript below.
> 
>  Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
>  adding that, e.g. by
> 
>    make LIBS_SYSTEM=-lssp
> 
> Yes, that works.

OK, thanks.

So do we need to add that library to the link command under some
conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
configure script (in which case I'm missing something, because I
didn't find it in the configure script), or is this an option you
added manually?  In the latter case, would configuring with LIBS=-lssp
be an okay solution?

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Richard Copley]

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

On Mon, 21 Oct 2019 at 14:32, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Richard Copley <rcopley@gmail.com>
> > Date: Mon, 21 Oct 2019 14:17:36 +0100
> > Cc: 37852@debbugs.gnu.org
> >
> > On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >  > From: Richard Copley <rcopley@gmail.com>
> >  > Date: Mon, 21 Oct 2019 13:28:29 +0100
> >  >
> >  > Linking auxiliary executables fails with undefined references to
> (FORTIFY_SOURCE?) functions
> >  > __memcpy_chk and __memmove_chk. This is apparently caused by some
> change in MSYS2,
> >  because
> >  > previously buildable commits now fail. Transcript below.
> >
> >  Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
> >  adding that, e.g. by
> >
> >    make LIBS_SYSTEM=-lssp
> >
> > Yes, that works.
>
> OK, thanks.
>
> So do we need to add that library to the link command under some
> conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
> configure script (in which case I'm missing something, because I
> didn't find it in the configure script),
>

I don't know.


> or is this an option you
> added manually?
>

No, I built in a clean checkout of master, with these commands:

./autogen.sh
./configure --without-pop --without-dbus --without-gconf
--without-gsettings "CFLAGS=-O2"
make

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

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 21 Oct 2019 15:04:34 +0100
> Cc: 37852@debbugs.gnu.org
> 
>  or is this an option you
>  added manually?
> 
> No, I built in a clean checkout of master, with these commands:
> 
> ./autogen.sh
> ./configure --without-pop --without-dbus --without-gconf --without-gsettings "CFLAGS=-O2"
> make

Hmm... okay, could you please grep Makefiles in lib-src/ and src/, and
see if FORTIFY_SOURCE appears in any of them?  If not, I guess the
references to those _chk functions are coming from some libraries
linked into the programs we compile, and that probably means we need
to use -lssp for MinGW just in case?

Possibly relevant discussion:

  https://github.com/msys2/MINGW-packages/issues/5803

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Andy Moreton]

On Mon 21 Oct 2019, Eli Zaretskii wrote:

>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 21 Oct 2019 14:17:36 +0100
>> Cc: 37852@debbugs.gnu.org
>> 
>> On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>  > From: Richard Copley <rcopley@gmail.com>
>>  > Date: Mon, 21 Oct 2019 13:28:29 +0100
>>  > 
>>  > Linking auxiliary executables fails with undefined references to (FORTIFY_SOURCE?) functions 
>>  > __memcpy_chk and __memmove_chk. This is apparently caused by some change in MSYS2,
>>  because
>>  > previously buildable commits now fail. Transcript below.
>> 
>>  Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
>>  adding that, e.g. by
>> 
>>    make LIBS_SYSTEM=-lssp
>> 
>> Yes, that works.
>
> OK, thanks.
>
> So do we need to add that library to the link command under some
> conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
> configure script (in which case I'm missing something, because I
> didn't find it in the configure script), or is this an option you
> added manually?  In the latter case, would configuring with LIBS=-lssp
> be an okay solution?

See GNULIB_PORTCHECK_FORTIFY_SOURCE in configure.ac - the relevant macro
is _FORTIFY_SOURCE.

Building with -D_FORTIFY_SOURCE=0 also works, but your suggestion to add
the missing library is a better workaround than disabling the checks.

    AndyM

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 21 Oct 2019 17:05:35 +0100
> 
> > So do we need to add that library to the link command under some
> > conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
> > configure script (in which case I'm missing something, because I
> > didn't find it in the configure script), or is this an option you
> > added manually?  In the latter case, would configuring with LIBS=-lssp
> > be an okay solution?
> 
> See GNULIB_PORTCHECK_FORTIFY_SOURCE in configure.ac - the relevant macro
> is _FORTIFY_SOURCE.

Thanks, I indeed missed that.

> Building with -D_FORTIFY_SOURCE=0 also works, but your suggestion to add
> the missing library is a better workaround than disabling the checks.

The problem with using -lssp unconditionally is that some
installations might not have it, and then the linker will barf.  So I
think we should better disable GNULIB_PORTCHECK on MinGW (I can hardly
imagine someone using that platform for those portability checks, and
I'm not sure I understand why this gets defined by default on other
platforms).

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> Date: Mon, 21 Oct 2019 19:36:17 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 37852@debbugs.gnu.org
> 
> > See GNULIB_PORTCHECK_FORTIFY_SOURCE in configure.ac - the relevant macro
> > is _FORTIFY_SOURCE.
> 
> Thanks, I indeed missed that.
> 
> > Building with -D_FORTIFY_SOURCE=0 also works, but your suggestion to add
> > the missing library is a better workaround than disabling the checks.

Btw, this sounds like a bug in MinGW64 headers: they shouldn't
generate references to the _chk functions without making sure,
e.g. via specs or somesuch, that libssp is linked against.  It's worth
reporting to the MSYS2 folks, I think.

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Paul Eggert]

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

> I think we should better disable GNULIB_PORTCHECK on MinGW (I can hardly
> imagine someone using that platform for those portability checks, and
> I'm not sure I understand why this gets defined by default on other
> platforms).

The intent of GNULIB_PORTCHECK is that it is enabled by developers who 
want some simple build-time portability tests. It isn't suitable for 
people who just want to build the software, as there are too many build 
failures and other false alarms that builders don't care about.

I installed the attached patch, to cause the problem to occur only if 
one configures explicitly with --enable-gcc-warnings. This should fix 
the problem that Richard reported. However, it won't fix the more 
general problem (which Richard should be able to reproduce via 
'./configure --enable-gcc-warnings ...').

Apparently MSYS2 changed recently, and this caused _FORTIFY_SOURCE 
builds to fail. See, for example:

https://github.com/msys2/MINGW-packages/issues/5803

I don't understand MSYS2 well enough to suggest fixes for Emacs, other 
than "don't configure with --enable-gcc-warnings and don't compile with 
_FORTIFY_SOURCE defined".

[-- Attachment #2: 0001-Portcheck-only-if-enable-gcc-warnings.patch --]
[-- Type: text/x-patch, Size: 1954 bytes --]

From 0ccd70a99b5cbd3cf7fea65c47a724846c578a43 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 21 Oct 2019 17:28:02 -0700
Subject: [PATCH] Portcheck only if --enable-gcc-warnings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Richard Copley (Bug#37852).
This patch causes the problem to not occur if one uses plain
‘configure’.  The problem can still occur if with ‘configure
--enable-gcc-warnings’, so a further fix may be needed.
* configure.ac (GNULIB_PORTCHECK, _FORTIFY_SOURCE):
Define these only with an explicit --enable-gcc-warnings.
---
 configure.ac | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 33d725c804..3b6a2a6d16 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1114,15 +1114,16 @@ AC_DEFUN
   fi
 
   AC_DEFINE([GCC_LINT], [1], [Define to 1 if --enable-gcc-warnings.])
-  AC_DEFINE([GNULIB_PORTCHECK], [1], [enable some gnulib portability checks])
-  AH_VERBATIM([GNULIB_PORTCHECK_FORTIFY_SOURCE],
-  [/* Enable compile-time and run-time bounds-checking, and some warnings,
-      without upsetting glibc 2.15+. */
-   #if (defined GNULIB_PORTCHECK && !defined _FORTIFY_SOURCE \
-        && defined __OPTIMIZE__ && __OPTIMIZE__)
-   # define _FORTIFY_SOURCE 2
-   #endif
-  ])
+  AS_IF([test $gl_gcc_warnings = yes],
+    [AC_DEFINE([GNULIB_PORTCHECK], [1], [enable some gnulib portability checks])
+     AH_VERBATIM([GNULIB_PORTCHECK_FORTIFY_SOURCE],
+     [/* Enable compile-time and run-time bounds-checking, and some warnings,
+	 without upsetting glibc 2.15+. */
+      #if (defined GNULIB_PORTCHECK && !defined _FORTIFY_SOURCE \
+	   && defined __OPTIMIZE__ && __OPTIMIZE__)
+      # define _FORTIFY_SOURCE 2
+      #endif
+     ])])
  ])
 
 # clang is picky about these regardless of whether
-- 
2.21.0

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> Cc: 37852@debbugs.gnu.org, Richard Copley <rcopley@gmail.com>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 21 Oct 2019 17:40:12 -0700
> 
> I installed the attached patch, to cause the problem to occur only if 
> one configures explicitly with --enable-gcc-warnings. This should fix 
> the problem that Richard reported.

Thanks.

> I don't understand MSYS2 well enough to suggest fixes for Emacs, other 
> than "don't configure with --enable-gcc-warnings and don't compile with 
> _FORTIFY_SOURCE defined".

Should we perhaps test for -lssp, and if it is found, add it to the
link command when we define _FORTIFY_SOURCE?

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Paul Eggert]

On 10/21/19 7:37 PM, Eli Zaretskii wrote:

>> I don't understand MSYS2 well enough to suggest fixes for Emacs, other
>> than "don't configure with --enable-gcc-warnings and don't compile with
>> _FORTIFY_SOURCE defined".
> 
> Should we perhaps test for -lssp, and if it is found, add it to the
> link command when we define _FORTIFY_SOURCE?

If this is done only on MSYS2 platforms, and if -lssp is used only when 
it causes otherwise-failing programs to work, then it should be OK. I 
wouldn't do it elsewhere because on Fedora at any rate, -lssp used to be 
trouble and was best avoided.

It vaguely sounds like MSYS2 is trailing Fedora and so is experiencing 
problems Fedora had a few years ago (see, e.g., 
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4973>).

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> Cc: 37852@debbugs.gnu.org, rcopley@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 22 Oct 2019 11:27:48 -0700
> 
> > Should we perhaps test for -lssp, and if it is found, add it to the
> > link command when we define _FORTIFY_SOURCE?
> 
> If this is done only on MSYS2 platforms, and if -lssp is used only when 
> it causes otherwise-failing programs to work, then it should be OK. I 
> wouldn't do it elsewhere because on Fedora at any rate, -lssp used to be 
> trouble and was best avoided.

Right.

> It vaguely sounds like MSYS2 is trailing Fedora and so is experiencing 
> problems Fedora had a few years ago (see, e.g., 
> <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4973>).

I actually think it's a bug in MSYS2, and hope they will fix it soon.
So perhaps we should just wait and see if the current situation, after
your patch, is good enough.

Thanks.

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Richard Copley]

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

On Tue, 22 Oct 2019 at 19:51, Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: 37852@debbugs.gnu.org, rcopley@gmail.com
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Tue, 22 Oct 2019 11:27:48 -0700
> >
> > > Should we perhaps test for -lssp, and if it is found, add it to the
> > > link command when we define _FORTIFY_SOURCE?
> >
> > If this is done only on MSYS2 platforms, and if -lssp is used only when
> > it causes otherwise-failing programs to work, then it should be OK. I
> > wouldn't do it elsewhere because on Fedora at any rate, -lssp used to be
> > trouble and was best avoided.
>
> Right.
>
> > It vaguely sounds like MSYS2 is trailing Fedora and so is experiencing
> > problems Fedora had a few years ago (see, e.g.,
> > <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4973>).
>
> I actually think it's a bug in MSYS2, and hope they will fix it soon.
> So perhaps we should just wait and see if the current situation, after
> your patch, is good enough.
>
> Thanks.
>

Just to confirm, this fix works for me. Thank you.

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

bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Wed, 23 Oct 2019 22:29:09 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 37852@debbugs.gnu.org
> 
> Just to confirm, this fix works for me. Thank you.

Thanks, closing.