mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'
Hi
I'm working on updating the mingw toolchain [1], and am hitting the situation [2] where I build with -fstack-protector in the ldflags, can confirm that -lssp and -lssp_nonshared are automatically added to the ldflags (seen via gcc -v [3] and strace), but I still get i.e. with this minimal testcase:
#include <dirent.h> int main () { return closedir (NULL); }
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector /usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f): undefined reference to `__strcpy_chk' collect2: error: ld returned 1 exit status
OTOH, if I write
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll
it links correctly.
The only other thing which came to mind to verify is that the import library references the correct dll, and this appears to be the case:
$ i686-w64-mingw32-dlltool -I /usr/i686-w64-mingw32/sys-root/mingw/lib/libssp.dll.a libssp-0.dll
I'd appreciate any pointers as I'm pretty much in the dark here.
Thanks Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-7.0.0/builds/
[2] Specifically when building mingw-gdb, which adds -D_FORTIFY_SOURCES=2 internally, hence adding -fstack-protector to the ldflags
[3] I.e. I gtt COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-fstack-protector' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-w64-mingw32/10.1.1/collect2 -plugin /usr/libexec/gcc/i686-w64-mingw32/10.1.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/i686-w64-mingw32/10.1.1/lto-wrapper -plugin-opt=-fresolution=/tmp/cckKHr8u.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt --sysroot=/usr/i686-w64-mingw32/sys-root -m i386pe -Bdynamic -o test.exe /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtbegin.o -L/usr/lib/gcc/i686-w64-mingw32/10.1.1 -L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib/../lib -L/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib -L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/sys-root/mingw/lib /tmp/ccpeowDx.o /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll -lssp_nonshared -lssp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtend.o
On Thu, 2020-07-09 at 00:07 +0200, Sandro Mani wrote:
I'm working on updating the mingw toolchain [1], and am hitting the situation [2] where I build with -fstack-protector in the ldflags, can confirm that -lssp and -lssp_nonshared are automatically added to the ldflags (seen via gcc -v [3] and strace), but I still get i.e. with this minimal testcase:
#include <dirent.h> int main () { return closedir (NULL); }
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector /usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f): undefined reference to `__strcpy_chk' collect2: error: ld returned 1 exit status
Perhaps mingw-crt should be built with -fno-stack-protector?
OTOH, if I write
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll
it links correctly.
The only other thing which came to mind to verify is that the import library references the correct dll, and this appears to be the case:
$ i686-w64-mingw32-dlltool -I /usr/i686-w64-mingw32/sys-root/mingw/lib/libssp.dll.a libssp-0.dll
I'd appreciate any pointers as I'm pretty much in the dark here.
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-7.0.0/builds/
[2] Specifically when building mingw-gdb, which adds -D_FORTIFY_SOURCES=2 internally, hence adding -fstack-protector to the ldflags
[3] I.e. I gtt COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-fstack-protector' '-mtune=generic' '-march=pentiumpro' /usr/libexec/gcc/i686-w64-mingw32/10.1.1/collect2 -plugin /usr/libexec/gcc/i686-w64-mingw32/10.1.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/i686-w64-mingw32/10.1.1/lto-wrapper -plugin-opt=-fresolution=/tmp/cckKHr8u.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt --sysroot=/usr/i686-w64-mingw32/sys-root -m i386pe -Bdynamic -o test.exe /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtbegin.o -L/usr/lib/gcc/i686-w64-mingw32/10.1.1 -L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib/../lib -L/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib -L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/sys-root/mingw/lib /tmp/ccpeowDx.o /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll -lssp_nonshared -lssp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtend.o
On Thu, Jul 09, 2020 at 12:07:38AM +0200, Sandro Mani wrote:
Hi
I'm working on updating the mingw toolchain [1], and am hitting the situation [2] where I build with -fstack-protector in the ldflags, can confirm that -lssp and -lssp_nonshared are automatically added to the ldflags (seen via gcc -v [3] and strace), but I still get i.e. with this minimal testcase:
#include <dirent.h> int main () { return closedir (NULL); }
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector /usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f): undefined reference to `__strcpy_chk' collect2: error: ld returned 1 exit status
OTOH, if I write
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector /usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll
it links correctly.
The only other thing which came to mind to verify is that the import library references the correct dll, and this appears to be the case:
$ i686-w64-mingw32-dlltool -I /usr/i686-w64-mingw32/sys-root/mingw/lib/libssp.dll.a libssp-0.dll
I'd appreciate any pointers as I'm pretty much in the dark here.
I've hit something that seems semi-related to this in libvirt builds for mingw.
We always set _FORTIFY_SOURCE=2 but on mingw do NOT set any of the -fstack-protector args. This worked historically, but GCC 10 has broken it.
If I set _FORTIFY_SOURCE=2 without -fstack-protector-strong, then I get link failures:
/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: ./.libs/libvirt-net-rpc.a(libvirt_net_rpc_la-virnetsocket.o): in function `memcpy': /usr/i686-w64-mingw32/sys-root/mingw/include/string.h:202: undefined reference to `__memcpy_chk' /usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: ./.libs/libvirt_driver_remote.a(libvirt_driver_remote_la-remote_driver.o): in function `strcpy': /usr/i686-w64-mingw32/sys-root/mingw/include/string.h:228: undefined reference to `__memcpy_chk'
So I removed _FORTIFY_SOURCE=2 too, and now libvirt code works but linking to other libraries still fails
/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld: /usr/i686-w64-mingw32/sys-root/mingw/lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f): undefined reference to `__strcpy_chk'
The only way I can succesfully compile and link now is to always set both _FORTIFY_SOURCE=2 and -fstack-protector-strong.
I'm going to just make libvirt use -fstack-protector-strong now since we wanted it to use it on Mingw in the first place and only avoided it because it was broken on older Mingw versions many years back.
There does seem to be a bug somewhere in mingw / gcc 10 though. Whatever changed in GCC 10 for mingw, appears to have made the stack-protector stuff mandatory, which feels quite wrong.
Regards, Daniel
-
Daniel P. Berrangé -
Sandro Mani -
Yaakov Selkowitz