mingw July 2020

mingw@lists.fedoraproject.org

3 participants
3 discussions

Re: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'
by Yaakov Selkowitz 04 Aug '20

04 Aug '20

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.

3 4

Retiring my gstreamer 0.10 packages
by Michael Cronenworth 31 Jul '20

31 Jul '20

The following packages are failing the F33 rebuild. I don't wish to fix them. * mingw-gstreamer-plugins-good * mingw-gstreamer-plugins-bad-free If anyone wants to take them let me know otherwise they will be retired in a few days. Thanks, Michael

1 1

mingw_cflags vs optflags
by Sandro Mani 02 Jul '20

02 Jul '20

Hi While looking through the mingw rpm macros, I noticed that we currently have mingw{32,64}_cflags = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 whereas for native packages we have optflags = -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection As I read the gcc docs and [1] (by no means an expert in the matter), I'd say the following might also make sense for the mingw cflags: - -Werror=format-security - -Wp,-D_GLIBCXX_ASSERTIONS - -fstack-protector-strong - -fasynchronous-unwind-tables - -fstack-clash-protection I've got a mass tool chain update scheduled before the F33 mass rebuild, I could in the same go also update the flags. Opinions? Sandro [1] https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw July 2020