* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) @ 2019-10-21 12:28 Richard Copley 2019-10-21 13:07 ` Eli Zaretskii 2019-10-22 0:40 ` Paul Eggert 0 siblings, 2 replies; 15+ messages in thread From: Richard Copley @ 2019-10-21 12:28 UTC (permalink / raw) To: 37852 [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 12:28 bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) Richard Copley @ 2019-10-21 13:07 ` Eli Zaretskii 2019-10-21 13:17 ` Richard Copley 2019-10-22 0:40 ` Paul Eggert 1 sibling, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-10-21 13:07 UTC (permalink / raw) To: Richard Copley; +Cc: 37852 > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 13:07 ` Eli Zaretskii @ 2019-10-21 13:17 ` Richard Copley 2019-10-21 13:31 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Richard Copley @ 2019-10-21 13:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 37852 [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 13:17 ` Richard Copley @ 2019-10-21 13:31 ` Eli Zaretskii 2019-10-21 14:04 ` Richard Copley 2019-10-21 16:05 ` Andy Moreton 0 siblings, 2 replies; 15+ messages in thread From: Eli Zaretskii @ 2019-10-21 13:31 UTC (permalink / raw) To: Richard Copley; +Cc: 37852 > 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 13:31 ` Eli Zaretskii @ 2019-10-21 14:04 ` Richard Copley 2019-10-21 16:01 ` Eli Zaretskii 2019-10-21 16:05 ` Andy Moreton 1 sibling, 1 reply; 15+ messages in thread From: Richard Copley @ 2019-10-21 14:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 37852 [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 14:04 ` Richard Copley @ 2019-10-21 16:01 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2019-10-21 16:01 UTC (permalink / raw) To: Richard Copley; +Cc: 37852 > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 13:31 ` Eli Zaretskii 2019-10-21 14:04 ` Richard Copley @ 2019-10-21 16:05 ` Andy Moreton 2019-10-21 16:36 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Andy Moreton @ 2019-10-21 16:05 UTC (permalink / raw) To: 37852 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 16:05 ` Andy Moreton @ 2019-10-21 16:36 ` Eli Zaretskii 2019-10-21 16:55 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-10-21 16:36 UTC (permalink / raw) To: Andy Moreton; +Cc: 37852 > 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). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 16:36 ` Eli Zaretskii @ 2019-10-21 16:55 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2019-10-21 16:55 UTC (permalink / raw) To: andrewjmoreton; +Cc: 37852 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-21 12:28 bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) Richard Copley 2019-10-21 13:07 ` Eli Zaretskii @ 2019-10-22 0:40 ` Paul Eggert 2019-10-22 2:37 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Paul Eggert @ 2019-10-22 0:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Richard Copley, 37852 [-- 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 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-22 0:40 ` Paul Eggert @ 2019-10-22 2:37 ` Eli Zaretskii 2019-10-22 18:27 ` Paul Eggert 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-10-22 2:37 UTC (permalink / raw) To: Paul Eggert; +Cc: rcopley, 37852 > 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? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-22 2:37 ` Eli Zaretskii @ 2019-10-22 18:27 ` Paul Eggert 2019-10-22 18:51 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Paul Eggert @ 2019-10-22 18:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rcopley, 37852 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>). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-22 18:27 ` Paul Eggert @ 2019-10-22 18:51 ` Eli Zaretskii 2019-10-23 21:29 ` Richard Copley 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2019-10-22 18:51 UTC (permalink / raw) To: Paul Eggert; +Cc: rcopley, 37852 > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-22 18:51 ` Eli Zaretskii @ 2019-10-23 21:29 ` Richard Copley 2019-10-24 13:50 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Richard Copley @ 2019-10-23 21:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, 37852 [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) 2019-10-23 21:29 ` Richard Copley @ 2019-10-24 13:50 ` Eli Zaretskii 0 siblings, 0 replies; 15+ messages in thread From: Eli Zaretskii @ 2019-10-24 13:50 UTC (permalink / raw) To: Richard Copley; +Cc: eggert, 37852-done > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-10-24 13:50 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-10-21 12:28 bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) Richard Copley 2019-10-21 13:07 ` Eli Zaretskii 2019-10-21 13:17 ` Richard Copley 2019-10-21 13:31 ` Eli Zaretskii 2019-10-21 14:04 ` Richard Copley 2019-10-21 16:01 ` Eli Zaretskii 2019-10-21 16:05 ` Andy Moreton 2019-10-21 16:36 ` Eli Zaretskii 2019-10-21 16:55 ` Eli Zaretskii 2019-10-22 0:40 ` Paul Eggert 2019-10-22 2:37 ` Eli Zaretskii 2019-10-22 18:27 ` Paul Eggert 2019-10-22 18:51 ` Eli Zaretskii 2019-10-23 21:29 ` Richard Copley 2019-10-24 13:50 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.