Mingw "code hardening" compilation error

Alexander Voropay

unread,

Jan 1, 2020, 11:09:10 AM1/1/20

to ARAnyM

Hi!

./configure script enables code hardening on the Mingw platform.

As a result linking fails:

CXXLD gencpu.exe

C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: gencpu.o: in function `sprintf':

C:/msys32/mingw32/i686-w64-mingw32/include/stdio.h:909: undefined reference to `__chk_fail'

C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys32/mingw32/i686-w64-mingw32/include/stdio.h:909: undefined reference to `__chk_fail'

C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: gencpu.o: in function `strcpy':

C:/msys32/mingw32/i686-w64-mingw32/include/string.h:228: undefined reference to `__strcpy_chk'

C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys32/mingw32/i686-w64-mingw32/include/string.h:228: undefined reference to `__strcpy_chk'

C:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: gencpu.o: in function `strcat':

C:/msys32/mingw32/i686-w64-mingw32/include/string.h:234: undefined reference to `__strcat_chk'

...

[alot of errors skipped]

To resolve this issue I've commented in the config.h

...

/*

#ifndef _FORTIFY_SOURCE

# if defined __OPTIMIZE__ && __OPTIMIZE__ > 0

# define _FORTIFY_SOURCE 2

# endif

#endif

*/

...

I don't know the current status of the code hardening on the Mingw platform.

Is there a minimal test ? Should I just include -lssp ?

--=AV=-

Thorsten Otto

unread,

Jan 1, 2020, 11:39:54 AM1/1/20

to ara...@googlegroups.com

On Mittwoch, 1. Januar 2020 17:09:10 CET Alexander Voropay wrote:

> C:/msys32/mingw32/i686-w64-mingw32/include/string.h:234: undefined

> reference to `__strcat_chk'

Looks like a mismatch between the header files and the libraries. If the header files redirect strcat to __strcat_chk if _FORTIFY_SOURCE is defined, then of course the library must provide that symbol. Where did you get that compiler from? I'm using the one from the MSYS2 project, which is 7.3.0

>To resolve this issue I've commented in the config.h

I've included that on purpose, because that is normally also defined by most distros when building the package via rpm or similar. Maybe it should be ommitted for MinGW, but not in general.

>Should I just include -lssp ?

Might help in this case, but maybe its just better do disable the checks for mingw. It will be hard to figure out in configure, whether that library is needed.

>cdrom.cpp:548:92: warning: cast between incompatible function types

Will have a look, but seems harmless.

Alexander Voropay

unread,

Jan 2, 2020, 6:00:59 AM1/2/20

to ARAnyM

On Wednesday, January 1, 2020 at 7:39:54 PM UTC+3, Thorsten Otto wrote:

. Where did you get that compiler from? I'm using the one from the MSYS2 project, which is 7.3.0

I'm using a recent MSYS2 with Mingw32 target.

Note, MSYS2 now has 3(!!!) different shells (and build systems):

MSYS intesf, mingw32 ang mingw64

https://github.com/msys2/msys2/wiki/MSYS2-installation

https://github.com/orlp/dev-on-windows/wiki/Installing-GCC--&-MSYS2

So I've installed 32-bit MSYS2 and "base-devel" and "mingw-w64-i686-toolchain"

groups w/o MSYS2 toolcains and run mingw32.exe shell

This brings me 'native' development system, not a cross-build

$ ./configure

configure: loading site script /mingw32/etc/config.site

checking build system type... i686-w64-mingw32

checking host system type... i686-w64-mingw32

...

I have successfully built git's ARAnyM for mingw32 target. It works and even correctly

determines user's home directory C:\Usesrs\alecv\...

There is one small issue: it uses alot of mingw's DLL's :

$ ldd aranym.exe

ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x771f0000)

kernel32.dll => /c/Windows/system32/kernel32.dll (0x76230000)

KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x75070000)

ADVAPI32.dll => /c/Windows/system32/ADVAPI32.dll (0x767c0000)

msvcrt.dll => /c/Windows/system32/msvcrt.dll (0x76870000)

sechost.dll => /c/Windows/SYSTEM32/sechost.dll (0x77380000)

RPCRT4.dll => /c/Windows/system32/RPCRT4.dll (0x754d0000)

SHELL32.dll => /c/Windows/system32/SHELL32.dll (0x755e0000)

SHLWAPI.dll => /c/Windows/system32/SHLWAPI.dll (0x76920000)

GDI32.dll => /c/Windows/system32/GDI32.dll (0x75480000)

USER32.dll => /c/Windows/system32/USER32.dll (0x75290000)

LPK.dll => /c/Windows/system32/LPK.dll (0x77350000)

USP10.dll => /c/Windows/system32/USP10.dll (0x76460000)

libgcc_s_dw2-1.dll => /mingw32/bin/libgcc_s_dw2-1.dll (0x6eb40000)

libwinpthread-1.dll => /mingw32/bin/libwinpthread-1.dll (0x64b40000)

libstdc++-6.dll => /mingw32/bin/libstdc++-6.dll (0x6fe40000)

libgmp-10.dll => /mingw32/bin/libgmp-10.dll (0x6aec0000)

libjpeg-8.dll => /mingw32/bin/libjpeg-8.dll (0x65780000)

SDL2.dll => /c/build/aranym/SDL2.dll (0x5cf70000)

IMM32.DLL => /c/Windows/system32/IMM32.DLL (0x773e0000)

MSCTF.dll => /c/Windows/system32/MSCTF.dll (0x753b0000)

ole32.dll => /c/Windows/system32/ole32.dll (0x76c50000)

OLEAUT32.dll => /c/Windows/system32/OLEAUT32.dll (0x76a10000)

SETUPAPI.dll => /c/Windows/system32/SETUPAPI.dll (0x76ab0000)

CFGMGR32.dll => /c/Windows/system32/CFGMGR32.dll (0x74f90000)

DEVOBJ.dll => /c/Windows/system32/DEVOBJ.dll (0x75010000)

VERSION.dll => /c/Windows/system32/VERSION.dll (0x73f30000)

WINMM.DLL => /c/Windows/system32/WINMM.DLL (0x730a0000)

zlib1.dll => /mingw32/bin/zlib1.dll (0x63080000)

--

-=AV=-

Thorsten Otto

unread,

Jan 2, 2020, 10:57:16 AM1/2/20

to ara...@googlegroups.com

On Donnerstag, 2. Januar 2020 12:00:59 CET Alexander Voropay wrote:

> I'm using a recent MSYS2 with Mingw32 target.

Ah ok, i haven't updated it for quite some time.

>Note, MSYS2 now has 3(!!!) different shells (and build systems):

>MSYS intesf, mingw32 ang mingw64

Yes, but 64-bit targets are currently not supported on windows (also not for cygwin). Maybe the "normal" target works, but for JIT i yet have to figure out how to install the exception handler, and how to enforce a virtual address in the 32bit range.

>There is one small issue: it uses alot of mingw's DLL's

That could be, but only a few of them are directly referenced by aranym (zlib, jpeg-8 and SDL). winpthread, gcc_s and stdc++ are needed by the toolchain. Others are referenced by windows libraries, and mostly depend on the windows version. Only libgmp looks a bit dubious, maybe that is now needed by libgcc_s, for decimal floats? On windows7, with that older compiler, i get

       ADVAPI32.dll => C:\Windows\SysWOW64\ADVAPI32.dll (0x77c60000)
       msvcrt.dll => C:\Windows\SysWOW64\msvcrt.dll (0x6ff50000)
       KERNELBASE.dll => C:\Windows\SysWOW64\KERNELBASE.dll (0x7d850000)
       ntdll.dll => C:\Windows\SysWOW64\ntdll.dll (0x7de70000)
       KERNEL32.dll => C:\Windows\SysWOW64\KERNEL32.dll (0x7dd60000)
       RPCRT4.dll => C:\Windows\SysWOW64\RPCRT4.dll (0x7db50000)
       SspiCli.dll => C:\Windows\SysWOW64\SspiCli.dll (0x7d8a0000)
       CRYPTBASE.dll => C:\Windows\SysWOW64\CRYPTBASE.dll (0x10000000)
       SHELL32.dll => C:\Windows\SysWOW64\SHELL32.dll (0x73800000)
       SHLWAPI.dll => C:\Windows\SysWOW64\SHLWAPI.dll (0x6de20000)
       GDI32.dll => C:\Windows\SysWOW64\GDI32.dll (0x7dab0000)
       USER32.dll => C:\Windows\SysWOW64\USER32.dll (0x7dc50000)
       LPK.dll => C:\Windows\SysWOW64\LPK.dll (0x7d620000)
       USP10.dll => C:\Windows\SysWOW64\USP10.dll (0x6f8e0000)
       libgcc_s_dw2-1.dll => C:\mingw32\bin\libgcc_s_dw2-1.dll (0x6eb40000)
       libwinpthread-1.dll => C:\mingw32\bin\libwinpthread-1.dll (0x64b40000)
       libstdc++-6.dll => C:\mingw32\bin\libstdc++-6.dll (0x6fe40000)
       libjpeg-8.dll => C:\mingw32\bin\libjpeg-8.dll (0x6ba00000)
       SDL.dll => C:\mingw32\bin\SDL.dll (0x68300000)
       WINMM.DLL => C:\Windows\SysWOW64\WINMM.DLL (0x41b00000)
       libusb-1.0.dll => C:\mingw32\bin\libusb-1.0.dll (0x6b800000)

Reply all

Reply to author

Forward