mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

[Sandro Mani]

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

[Yaakov Selkowitz]

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 
-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

[Daniel P. Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|