Re: mingw GCC help needed: -fstack-protector and -lssp, undefined
reference to `__strcpy_chk'
by 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.
3 years, 9 months
Retiring my gstreamer 0.10 packages
by Michael Cronenworth
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
3 years, 9 months
mingw_cflags vs optflags
by Sandro Mani
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/
3 years, 10 months
