MinGW-w64 - for 32 and 64 bit Windows / Bugs / #818 undefined reference to `__strcpy_chk' with -D_FORTIFY_SOURCE=2 or -D_FORTIFY

Brecht Sanders - 2019-11-13

Seems similar to this post in the mailing list:
https://sourceforge.net/p/mingw-w64/mailman/message/36764708/
At the end of the thread there was a mention of a patch being pushed.
Was this not included in release 7.0.0 released at the following link?
http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-13

Why did you remove -fstack-protector? In mingw-w64 _FORTIFY_SOURCE requires either -lssp or -fstack-protector to work.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Because then I had other issues. If I leave it in I get:

R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:17: undefined reference to `__stack_chk_guard'
d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:104: undefined reference to `__stack_chk_guard'
d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:104: undefined reference to `__stack_chk_fail'
d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: crypto_scrypt-hash.o: in function `libscrypt_hash':
R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-hash.c:11: undefined reference to `__stack_chk_guard'
d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-hash.c:44: undefined reference to `__stack_chk_guard'
d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-hash.c:44: undefined reference to `__stack_chk_fail'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile.mingw:17: libscrypt.dll] Error 1

LIU Hao - 2019-11-13

Check your linker command line to make sure -lssp exists (note it is a GCC library so it must exist unless your toolchain is broken). You probably have to add it in LDADD if you also have -nostdlib.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-14

With -lssp I still get undefined reference to '__strcpy_chk'
When using -fstack-protector -lssp I get:d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function 'libscrypt_SHA256_Final': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:290: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function 'libscrypt_HMAC_SHA256_Init': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:326: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function 'libscrypt_HMAC_SHA256_Final': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:354: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function 'libscrypt_PBKDF2_SHA256': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:411: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o:sha256.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0): undefined reference to '__stack_chk_guard' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: crypto-scrypt-saltgen.o: in function 'libscrypt_salt_gen': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/crypto-scrypt-saltgen.c:48: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: crypto_scrypt-check.o: in function 'libscrypt_check': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:104: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: crypto_scrypt-hash.o: in function 'libscrypt_hash': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-hash.c:44: undefined reference to '__stack_chk_fail'
Note that -nostdlib is not used.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-15

Please provide the full linker command line. The order of -l options is significant hence -lssp must follow all .o files.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

When I add this to Makefile.mingw to make sure the compiler options is specified after the .o files:

%.o: %.c
    $(CC) -c -o $@ $< $(CFLAGS)

this is the output:

$ make -f Makefile.mingw CC=gcc V=1 && echo OK
gcc -c -o crypto_scrypt-nosse.o crypto_scrypt-nosse.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o sha256.o sha256.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o crypto-mcf.o crypto-mcf.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o b64.o b64.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp

gcc -c -o crypto-scrypt-saltgen.o crypto-scrypt-saltgen.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o crypto_scrypt-check.o crypto_scrypt-check.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o crypto_scrypt-hash.o crypto_scrypt-hash.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o slowequals.o slowequals.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o main.o main.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc -c -o crypto_scrypt-hexconvert.o crypto_scrypt-hexconvert.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp
gcc  -s -Wl,--out-implib,libscrypt.dll.a -Wl,--version-script=libscrypt.version
-shared -o libscrypt.dll  crypto_scrypt-nosse.o sha256.o crypto-mcf.o b64.o crypto-scrypt-saltgen.o crypto_scrypt-check.o crypto_scrypt-hash.o slowequals.o -lm

d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function `libscrypt_SHA256_Final':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:290: undefined reference to `__stack_chk_fail'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function `libscrypt_HMAC_SHA256_Init':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:326: undefined reference to `__stack_chk_fail'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function `libscrypt_HMAC_SHA256_Final':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:354: undefined reference to `__stack_chk_fail'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function `libscrypt_PBKDF2_SHA256':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:411: undefined reference to `__stack_chk_fail'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o:sha256.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0): undefined reference to `__stack_chk_guard'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: crypto-scrypt-saltgen.o: in function `libscrypt_salt_gen':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/crypto-scrypt-saltgen.c:48: undefined reference to `__stack_chk_fail'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: crypto_scrypt-check.o: in function `libscrypt_check':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:104: undefined reference to `__stack_chk_fail'
d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: crypto_scrypt-hash.o: in function `libscrypt_hash':
R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-hash.c:44: undefined reference to `__stack_chk_fail'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile.mingw:20: libscrypt.dll] Error 1

LIU Hao - 2019-11-16

No this is the recipe for .o files. You must append -lssp to the recipe for the DLL.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-16

Just noticed building cairo (v1.16.0) with MinGW-w64 7.0.0 also fails with undefined reference to '__strncat_chk'

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-16

I did some more tests and figured out -fstack-protector is also needed when linking, not just when compiling.
Several projects don't seem to configure their build systems like this (so for I found this to be true for libscrypt and cairo).
These libraries did build against MinGW-w64 6.0.0 with the same compiler (GCC 9.2).
What exactly changed?

Last edit: Brecht Sanders 2019-11-16

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-17

See https://github.com/msys2/MINGW-packages/issues/5803.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-20

What will be done to solve this issue?
In the meantime I also noticed the following packages also won't build with MinGW-w64 7.0.0:

acpica

gdb

hashdeep

htmldoc

libopus

libressl

libsndfile

libsodium

openttd

ruby

stunnel

xapian
Some of these were mentioned in #5803.
So it' clearly breaking multiple builds that were working before (with MinGW-w64 6.0.0).

Last edit: Brecht Sanders 2019-11-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- LIU Hao - 2019-11-21
  
  The best suggestion would be tampering with GCC default libs and enfore -lssp there, but it looks so wrong to me, because for example on Linux if you need math functions you must link your program against -lm which GCC doesn't do by default (G++ adds it however). Probably we should have documented such requirements of _FORTIFY_SOURCE somewhere.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-21

Could it be an option to always export the __*_chk functions so these link errors can be avoided if any component in the link process needs them?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-21

No, because libssp is a GCC library which we don't provide.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-22

I get that, but I'm still confused.
If I used the same GCC version with MinGW-w64 6.0.0 it worked, but with MinGW-w64 7.0.0 it's broken. If this new version broke it, why can't it be fixed there?
Isn't it a goal of MinGW-w64 to be able to compile sources for Windows with as little changes as possible to the source packages?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-23

The modification has to be made in GCC source, not mingw-w64 source.

to compile sources for Windows with as little changes as possible is Cygwin's goal, not ours. Instead, our goal is to introduce as few overheads as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-25

Okay. I will change my building recipes to work around the problem by linking with -lssp whenever needed.
In many cases adding this after the ./configure line works: LIBS="-Wl,--as-needed -lssp"
For example mono builds fine now after only adding this. On the other had gdb needed a lot more tweaking, but I got it to build in the end.

I have added this solution to the web page of my personal standalone build at: http://winlibs.com/.

You can go ahead and close this ticket.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-25

For your reference, we have had -fstack-protector in LDFLAGS for GDB which implies -lssp in MSYS2.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-25

status: open --> closed-wont-fix
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-27

I just found out GCC can be built with an option --enable-default-ssp.
I will try that and see if my entire package collection builds fine with a GCC built like that.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-27

Thank you for reminding that thing to me. Now I am considering whether it is a good thing to have by default, as it introduces another DLL dependency in addition to libgcc and libstdc++.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Brecht Sanders - 2019-11-29
  
  I just wanted to let you know that I have built GCC 9.2.0 with --enable-default-ssp and used that to build a number of libraries. It appears however this does not resolve the problem, i.e. linking still requires -fstack-protector or -lssp to resolve the undefined references.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

LIU Hao - 2019-11-30

I presume you were using libtool to build dynamic libraries? Then unfortunately you have to add ssp in configure.ac using AC_CHECK_LIB, as libtool performs autocratic (punning intended) linking so you might have to tell it to link against libssp explicitly.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brecht Sanders - 2019-11-30

No, some projects were not using autoconf/libtool. That is why I was using libscrypt as an interesting case to reproduce ths problem.
The steps to reproduce are:

wget -c https://github.com/technion/libscrypt/archive/v1.21.tar.gz tar xfz v1.21.tar.gz cd libscrypt-1.21 sed -e "s/-Wl,-z,now\|-Wl,-z,relro\|-lc//g; s/-Wl,-soname,$[a-z]*$\.so\.[0-9]*/-s -Wl,--out-implib,\1.dll.a/; s/\.so\.[0-9]*/.dll/g; s/ln -s/echo SKIPPING &/g" Makefile > Makefile.mingw make -f Makefile.mingw CC=gcc

When using gcc built with --enable-default-ssp this now results in undefined references to __stack_chk_guard and __stack_chk_fail, which is different than before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

undefined reference to `__strcpy_chk' with -D_FORTIFY_SOURCE=2 or...

A complete runtime environment for gcc

Group

Searches

Help

#818 undefined reference to `__strcpy_chk' with -D_FORTIFY_SOURCE=2 or -D_FORTIFY_SOURCE=1

Discussion