Closed lhmouse closed 5 years ago
actually it does now, but its broken as hell :S
in mingw_mac.h in the latest update you will find this ->
#if _FORTIFY_SOURCE > 0 && __OPTIMIZE__ > 0 && __MINGW_GNUC_PREREQ(4, 1)
# if _FORTIFY_SOURCE > 1
# define __MINGW_FORTIFY_LEVEL 2
# else
# define __MINGW_FORTIFY_LEVEL 1
# endif
#else
# define __MINGW_FORTIFY_LEVEL 0
#endif
if you do a search in the headers for MINGW_FORTIFY_LEVEL you will notice some inlined chk functions.
Unfortunatly these dont seem to work correctly at the moment and you will get errors about undefined __chk functions in some sources if you remove the -D_FORTIFY_SOURCE flag.
instead set it to -D_FORTIFY_SOURCE=0 to force it off.
Yeah it seems these are SSP redirects so it gets a bit hairy.
unfortunatly setting -D_FORTIFY_SOURCE=0 is also not enough i discovered,
it still complains about __chk_fail being undefined :/ so the macro seems to be broken somehow.
Urgh wait a sec, i know why it fails...
previous packages have all been built with -D_FORTIFY_SOURCE=2 and the flag was propagated to the config files for several libraries.
So it seems we will have to rebuild an unknown amount of packages with -D_FORTIFY_SOURCE=0 so that the compiler will not pick up this setting from some other library config.
would building the crt against libssp with -fstack-protector-all be a workaround or would the redirects still require libssp to be linked in externally ?.
If it works it would unfortunatly make builds require yet another dll (libssp-0.dll) unless we linked in the static version.
Not sure if the libssp functions would at all be added to the crt libraries though seing that the redirects are mere macros for picking up libssp functions, and not real imports.
Before building libssp the CRT has to exist, so I don't think it is in principle correct to have the CRT link against libssp.
Aye it would be a nasty workaround, would probably be better to just incorporate the ssp code in the crt. But that might cause some nastiness when some source tries to use libssp :S eg. multiple definitions unless the function names are changed to follow the crt naming scheme like __chk_fail instead of __stack_chk_fail etc.
Just throwing around some ideas atm.
That could also bring licensing issues. Also if libssp code ever changes how should we synchronize with the upstream?
Let's see how everything goes for some moments. New packages should now be built without this option. Perhaps we will want to enable this in the future (it can't be enabled when building GCC but may be enable-able for others).
Neither if building the crt it would seem. Atleast the libc folks says to avoid doing that.
After rebuilding the affected packages without _FORTIFY_SOURCE i had no problems atleast.
btw. the -fstack-protector* flags should autoinclude libssp so there should be no need to force linking to libssp with LIBS+=" -lssp". If it does not then there are other problems upstream.
Yes this thing should be only be enabled conditionally - mostly, but at least not always.
If ppl want to enable this thing they had better add it themselves.
gdb-git can't be built due to following errors:
lh_mouse@lhmouse-pc /e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb $ make V=1
CONFIG_HEADERS=config.h:config.in \
CONFIG_COMMANDS="default depdir" \
CONFIG_FILES= \
CONFIG_LINKS= \
/bin/sh config.status
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default commands
config.status: executing depdir commands
make[1]: Entering directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb'
make[2]: Entering directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib'
make[3]: Entering directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib'
make[4]: Entering directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib/import'
make all-recursive
make[5]: Entering directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib/import'
make[6]: Entering directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib/import'
make[6]: Nothing to be done for 'all-am'.
make[6]: Leaving directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib/import'
make[5]: Leaving directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib/import'
make[4]: Leaving directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib/import'
make[3]: Leaving directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib'
make[2]: Leaving directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb/build-gnulib'
make[1]: Leaving directory '/e/GitHub/MINGW-packages-dev/mingw-w64-gdb-git/src/build-x86_64-w64-mingw32/gdb'
rm -f gdb.exe
x86_64-w64-mingw32-g++ -march=x86-64 -mtune=generic -O2 -pipe -pipe -pthread -Wl,--stack,12582912 \
-o gdb.exe gdb.o ada-exp.o ada-lang.o ada-tasks.o ada-typeprint.o ada-valprint.o ada-varobj.o addrmap.o agent.o amd64-tdep.o amd64-windows-nat.o amd64-windows-tdep.o annotate.o arch-utils.o arch/amd64.o arch/i386.o auto-load.o auxv.o ax-gdb.o ax-general.o bcache.o bfd-target.o block.o blockframe.o break-catch-sig.o break-catch-syscall.o break-catch-throw.o breakpoint.o btrace.o build-id.o buildsym-legacy.o buildsym.o c-exp.o c-lang.o c-typeprint.o c-valprint.o c-varobj.o charset.o cli-out.o cli/cli-cmds.o cli/cli-decode.o cli/cli-dump.o cli/cli-interp.o cli/cli-logging.o cli/cli-script.o cli/cli-setshow.o cli/cli-style.o cli/cli-utils.o coff-pe-read.o coffread.o common/agent.o common/btrace-common.o common/buffer.o common/cleanups.o common/common-debug.o common/common-exceptions.o common/common-regcache.o common/common-utils.o common/environ.o common/errors.o common/fileio.o common/filestuff.o common/format.o common/gdb_tilde_expand.o common/gdb_vecs.o common/job-control.o common/mingw-strerror.o common/netstuff.o common/new-op.o common/pathstuff.o common/print-utils.o common/ptid.o common/rsp-low.o common/run-time-clock.o common/scoped_mmap.o common/signals-state-save-restore.o common/signals.o common/tdesc.o common/vec.o common/xml-utils.o compile/compile-c-support.o compile/compile-c-symbols.o compile/compile-c-types.o compile/compile-cplus-symbols.o compile/compile-cplus-types.o compile/compile-loc2c.o compile/compile-object-load.o compile/compile-object-run.o compile/compile.o complaints.o completer.o continuations.o copying.o corefile.o corelow.o cp-abi.o cp-name-parser.o cp-namespace.o cp-support.o cp-valprint.o ctf.o d-exp.o d-lang.o d-namespace.o d-valprint.o dbxread.o dcache.o debug.o demangle.o dictionary.o disasm-selftests.o disasm.o dtrace-probe.o dummy-frame.o dwarf-index-cache.o dwarf-index-common.o dwarf-index-write.o dwarf2-frame-tailcall.o dwarf2-frame.o dwarf2expr.o dwarf2loc.o dwarf2read.o elfread.o eval.o event-loop.o event-top.o exceptions.o exec.o expprint.o extension.o f-exp.o f-lang.o f-typeprint.o f-valprint.o filename-seen-cache.o filesystem.o findcmd.o findvar.o frame-base.o frame-unwind.o frame.o gcore.o gdb-dlfcn.o gdb_bfd.o gdb_obstack.o gdb_regex.o gdb_usleep.o gdbarch-selftests.o gdbarch.o gdbtypes.o gnu-v2-abi.o gnu-v3-abi.o go-exp.o go-lang.o go-typeprint.o go-valprint.o guile/guile.o i386-cygwin-tdep.o i386-tdep.o i387-tdep.o inf-child.o inf-loop.o infcall.o infcmd.o inferior.o inflow.o infrun.o inline-frame.o interps.o jit.o language.o linespec.o location.o m2-exp.o m2-lang.o m2-typeprint.o m2-valprint.o macrocmd.o macroexp.o macroscope.o macrotab.o main.o maint.o mdebugread.o mem-break.o memattr.o memory-map.o memrange.o mi/mi-cmd-break.o mi/mi-cmd-catch.o mi/mi-cmd-disas.o mi/mi-cmd-env.o mi/mi-cmd-file.o mi/mi-cmd-info.o mi/mi-cmd-stack.o mi/mi-cmd-target.o mi/mi-cmd-var.o mi/mi-cmds.o mi/mi-common.o mi/mi-console.o mi/mi-getopt.o mi/mi-interp.o mi/mi-main.o mi/mi-out.o mi/mi-parse.o mi/mi-symbol-cmds.o mingw-hdep.o minidebug.o minsyms.o mipsread.o namespace.o nat/x86-dregs.o objc-lang.o objfiles.o observable.o opencl-lang.o osabi.o osdata.o p-exp.o p-lang.o p-typeprint.o p-valprint.o parse.o printcmd.o probe.o process-stratum-target.o producer.o progspace-and-thread.o progspace.o prologue-value.o psymtab.o python/py-arch.o python/py-auto-load.o python/py-block.o python/py-bpevent.o python/py-breakpoint.o python/py-cmd.o python/py-continueevent.o python/py-event.o python/py-evtregistry.o python/py-evts.o python/py-exitedevent.o python/py-finishbreakpoint.o python/py-frame.o python/py-framefilter.o python/py-function.o python/py-gdb-readline.o python/py-inferior.o python/py-infevents.o python/py-infthread.o python/py-instruction.o python/py-lazy-string.o python/py-linetable.o python/py-newobjfileevent.o python/py-objfile.o python/py-param.o python/py-prettyprint.o python/py-progspace.o python/py-record-btrace.o python/py-record-full.o python/py-record.o python/py-signalevent.o python/py-stopevent.o python/py-symbol.o python/py-symtab.o python/py-threadevent.o python/py-type.o python/py-unwind.o python/py-utils.o python/py-value.o python/py-varobj.o python/py-xmethods.o python/python.o record-btrace.o record-full.o record.o regcache-dump.o regcache.o reggroups.o registry.o remote-fileio.o remote-notif.o remote.o reverse.o rust-exp.o rust-lang.o sentinel-frame.o ser-base.o ser-event.o ser-mingw.o ser-tcp.o serial.o skip.o solib-target.o solib.o source-cache.o source.o stabsread.o stack.o stap-probe.o std-regs.o symfile-debug.o symfile.o symmisc.o symtab.o target-dcache.o target-descriptions.o target-float.o target-memory.o target.o target/waitstatus.o test-target.o thread-iter.o thread.o tid-parse.o top.o tracefile-tfile.o tracefile.o tracepoint.o trad-frame.o tramp-frame.o tui/tui-command.o tui/tui-data.o tui/tui-disasm.o tui/tui-file.o tui/tui-hooks.o tui/tui-interp.o tui/tui-io.o tui/tui-layout.o tui/tui-out.o tui/tui-regs.o tui/tui-source.o tui/tui-stack.o tui/tui-win.o tui/tui-windata.o tui/tui-wingeneral.o tui/tui-winsource.o tui/tui.o typeprint.o ui-file.o ui-out.o ui-style.o user-regs.o utils.o valarith.o valops.o valprint.o value.o varobj.o version.o windows-nat.o windows-tdep.o x86-nat.o x86-tdep.o xml-builtin.o xml-support.o xml-syscall.o xml-tdesc.o init.o \
-lreadline ../opcodes/libopcodes.a ../bfd/libbfd.a -L./../zlib -lz /mingw64/lib/libintl.a /mingw64/lib/libiconv.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lncursesw -lm -lpython3.7m -lversion -lshlwapi -lm /mingw64/lib/libexpat.a /mingw64/lib/liblzma.a ../libiberty/libiberty.a -lws2_32 build-gnulib/import/libgnu.a /mingw64/lib/libiconv.a /mingw64/lib/libmpfr.a /mingw64/lib/libgmp.a
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: ada-tasks.o:ada-tasks.c:(.text+0xa63): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: amd64-tdep.o:amd64-tdep.c:(.text+0x1e99): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: amd64-windows-tdep.o:amd64-windows-tdep.c:(.text+0x14a9): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o:breakpoint.c:(.text+0x1c94): undefined reference to `__strcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o:breakpoint.c:(.text+0x1cb6): undefined reference to `__strcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o:breakpoint.c:(.text+0x5371): undefined reference to `__memset_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o:breakpoint.c:(.text+0xcf81): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cli/cli-decode.o:cli-decode.c:(.text+0x20e6): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cli/cli-decode.o:cli-decode.c:(.text+0x2159): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cli/cli-decode.o:cli-decode.c:(.text+0x21af): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: coffread.o:coffread.c:(.text+0x2263): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: common/buffer.o:buffer.c:(.text+0x361): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: dbxread.o:dbxread.c:(.text+0x42d): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: dwarf2read.o:dwarf2read.c:(.text+0x2bee1): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: dwarf2read.o:dwarf2read.c:(.text+0x2bee9): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: exec.o:exec.c:(.text+0x18f6): undefined reference to `__strncpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: i386-tdep.o:i386-tdep.c:(.text+0x5761): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: mem-break.o:mem-break.c:(.text+0x80): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: objc-lang.o:objc-lang.c:(.text+0x7a7): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: objc-lang.o:objc-lang.c:(.text+0xa83): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: objc-lang.o:objc-lang.c:(.text+0xbdd): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: objc-lang.o:objc-lang.c:(.text+0xf9b): more undefined references to `__memcpy_chk' follow
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: remote-fileio.o:remote-fileio.c:(.text+0x4f8): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: remote-fileio.o:remote-fileio.c:(.text+0x5ab): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: remote.o:remote.c:(.text+0x9ba9): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: remote.o:remote.c:(.text+0x13317): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: remote.o:remote.c:(.text+0x13741): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: remote.o:remote.c:(.text+0x13841): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: ser-base.o:ser-base.c:(.text+0x61): undefined reference to `__chk_fail'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: solib.o:solib.c:(.text+0xa5): undefined reference to `__strcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: solib.o:solib.c:(.text+0x15f): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text+0x58e): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text$_ZNK14host_float_opsIeE11from_targetEPK11floatformatPKhPe[_ZNK14host_float_opsIeE11from_targetEPK11floatformatPKhPe]+0x22a): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text$_ZNK14host_float_opsIeE11from_targetEPK11floatformatPKhPe[_ZNK14host_float_opsIeE11from_targetEPK11floatformatPKhPe]+0x26b): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text$_ZNK14host_float_opsIeE11from_targetEPK11floatformatPKhPe[_ZNK14host_float_opsIeE11from_targetEPK11floatformatPKhPe]+0x2a8): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text$_ZNK14host_float_opsIdE11from_targetEPK11floatformatPKhPd[_ZNK14host_float_opsIdE11from_targetEPK11floatformatPKhPd]+0x21a): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text$_ZNK14host_float_opsIdE11from_targetEPK11floatformatPKhPd[_ZNK14host_float_opsIdE11from_targetEPK11floatformatPKhPd]+0x263): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: target-float.o:target-float.c:(.text$_ZNK14host_float_opsIdE11from_targetEPK11floatformatPKhPd[_ZNK14host_float_opsIdE11from_targetEPK11floatformatPKhPd]+0x2a8): more undefined references to `__memcpy_chk' follow
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: tracepoint.o:tracepoint.c:(.text+0x94ca): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: tracepoint.o:tracepoint.c:(.text+0x980b): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: valprint.o:valprint.c:(.text+0x48f8): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: valprint.o:valprint.c:(.text+0x49ad): undefined reference to `__memcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: windows-nat.o:windows-nat.c:(.text+0x6a0): undefined reference to `__strcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: windows-nat.o:windows-nat.c:(.text+0x744): undefined reference to `__strcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: windows-nat.o:windows-nat.c:(.text+0x75a): undefined reference to `__strcpy_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: windows-nat.o:windows-nat.c:(.text+0x797): undefined reference to `__strcat_chk'
C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: windows-nat.o:windows-nat.c:(.text+0x7b2): undefined reference to `__strcpy_chk'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:1889: gdb.exe] Error 1
Seems it is defined in gdb/common/common-defs.h:
/* Some distros enable _FORTIFY_SOURCE by default, which on occasion
has caused build failures with -Wunused-result when a patch is
developed on a distro that does not enable _FORTIFY_SOURCE. We
enable it here in order to try to catch these problems earlier;
plus this seems like a reasonable safety measure. The check for
optimization is required because _FORTIFY_SOURCE only works when
optimization is enabled. If _FORTIFY_SOURCE is already defined,
then we don't do anything. */
#if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
#define _FORTIFY_SOURCE 2
#endif
packages still affected by this so far are libsndfile flac and ruby.
did -lssp
(in LIBS
) or -fstack-protector
(in LDFLAGS
) help?
with flac and libsndfile it worked but ruby will crash on every compile :/
Using _FORTIFY_SOURCE
should no longer be an issue now: https://www.msys2.org/news/#2022-10-10-libssp-is-no-longer-required
Please let us know if there are any issues.
Should we now enable it in makepkg?
Should we now enable it in makepkg?
sure, why not: https://github.com/msys2/MSYS2-packages/pull/3222
anyone else get a ton of errors in celt after this change ?
invalid use of 'builtin_va_arg_pack_len ()' invalid use of 'builtin_va_arg_pack ()'
followed by even more errors of the same kind :/
seems to be comming from these functions, mingw_callopen_warn_toomany mingw_callopen mingw_callsopen_warn_toomany mingw_callsopen
emacs also bails on me with undefined reference to `__stpcpy_chk'
emacs also bails on me with undefined reference to `__stpcpy_chk'
I am afraid we should implement this one. It's also good to add stpcpy()
. @mstorsjo
emacs also bails on me with undefined reference to `__stpcpy_chk'
I am afraid we should implement this one. It's also good to add
stpcpy()
. @mstorsjo
I'm kinda curious how you end up with that one since we literally don't have stpcpy()
in mingw-w64 at the moment - but I guess some compiler transform does it. Or did you get a full implementation of stpcpy()
from somewhere before (in libssp)? (In LLVM we've had to mark stpcpy
as unavailable on mingw, because otherwise it could occasionally transform calls to other standard functions into calls to stpcpy
.)
I can try to whip up a patch to add __stpcpy_chk
as part of the ssp routines; this was one that I left out entirely since I didn't think it would be possible for us to need it.
emacs also bails on me with undefined reference to `__stpcpy_chk'
mingw-w64-emacs
builds for me without issues. And it seems to be working.
Edit: Also, no issues building mingw-w64-celt
. All up-to-date with pacman -Syu
.
not sure where it gets the idea that i have it ? :/ i havent added anything besides the packages from this repo. unfortunatly while i can get the packages for the standard mingw-w64 compilers from repo i cannot do so with my own special build of them as the 32 bit version of mine uses sjlj exceptions not dwarf. This version which is based on the TDM compiler was to be suggested as a plugin to the other compilers we currently sport but i been hunting a bug in the shared pointer code for some time with it which turned out to be a fault in the mutex locking code (fixed now and works like a charm so far).
Did you rebuild mingw-w64-crt-git
(if you don't use the packaged version) after it was updated to include those symbols?
emacs also bails on me with undefined reference to `__stpcpy_chk'
I am afraid we should implement this one. It's also good to add
stpcpy()
. @mstorsjo
I don't think so, this is clearly compiler issue. Moreover there is no problem when using compilers provided by MSYS2.
aye im using the new crt as well, compiler is the same as yours except for one extra patch (which incidently does not use stpcpy :) it uses some atomic functions to do a little magic with exceptions ).
some older libraries were left from the previous version which still linked to libssp, could those be the problem ?.
some older libraries were left from the previous version which still linked to libssp, could those be the problem ?.
No, that shouldn’t cause such issues. You need to find which object files reference that symbol, reproduce building them so that they still keep referencing that symbol, then show us how to reproduce building that object file, with a reference to that symbol.
p.s both the original and mine fail in the same place so yeah it seems like some leftovers are kicking my butt.
ok did a search for that symbol in the libraries and it is not defined anywhere ??? but if i move -Wp,-D_FORTIFY_SOURCE=2 from CFLAGS to CPPFLAGS skipping the -Wp, like it was done in the old version it works huh.
i used this to look for the symbol -> find $path -name *.a | parallel "nm --defined-only {} 2>/dev/null | grep $symbol && echo {}" replace $path with the path containing the libraries and $symbol with the symbol to look for.
Don’t use --defined-only
, you’re looking for which object file has got an undefined reference to that symbol. And you may want to look for files named *.o
too, depending on where you’re looking.
But I don’t see why you’d even need to search for it - doesn’t the linker say which object file has the undefined reference?
unfortunatly not :S ld.exe: ntlib.o:ntlib.c:(.text+0x5f4): undefined reference to `__stpcpy_chk' this was the error from emacs. i have a nagging suspecion that it might pick it up from some msys2 library or object ill try without --defined-only and have a look at the *.o files as well.
unfortunatly not :S ld.exe: ntlib.o:ntlib.c:(.text+0x5f4): undefined reference to `__stpcpy_chk' this was the error from emacs. i have a nagging suspecion that it might pick it up from some msys2 library or object ill try without --defined-only and have a look at the *.o files as well.
There it did say it - in ntlib.o, built from ntlib.c.
ah you ment in the source being built ok though no function in there uses that symbol as far as i can see.
btw __stpcpy_chk was actually in the libssp source code so yeah it seems some old library or object file is passing it on.
ssp.o ___stack_chk_fail
ssp.o ___chk_fail
ssp.o ___stack_chk_fail_local
ssp.o ___stack_chk_guard
gets-chk.o ___gets_chk
memcpy-chk.o ___memcpy_chk
memmove-chk.o ___memmove_chk
mempcpy-chk.o ___mempcpy_chk
memset-chk.o ___memset_chk
snprintf-chk.o ___snprintf_chk
sprintf-chk.o ___sprintf_chk
stpcpy-chk.o ___stpcpy_chk <- here
strcat-chk.o ___strcat_chk
strcpy-chk.o ___strcpy_chk
strncat-chk.o ___strncat_chk
strncpy-chk.o ___strncpy_chk
vsnprintf-chk.o ___vsnprintf_chk
vsprintf-chk.o ___vsprintf_chk
ah you ment in the source being built ok though no function in there uses that symbol as far as i can see.
Well this is exactly the whole point that we’re looking for here. Can you reproduce building that object file, so that it still references that symbol? If yes, provide the relevant source files and command lines so that someone else can reproduce compiling that file - so we can figure out why you’re getting references to that symbol.
btw __stpcpy_chk was actually in the libssp source code so yeah it seems some old library or object file is passing it on.
No, that’s not how it works. Yes, libssp did provide this symbol, that’s why it worked for you before, but not anymore. It’s not like libssp is infecting your compile so that it makes other source files reference a different symbol.
well in that case im out of ideas...
the emacs source is from here build command is makepkg-mingw -c --skippgp --nocheck so pretty standard.
so far only affects emacs and celt it seems.
well in that case im out of ideas...
the emacs source is from here build command is makepkg-mingw -c --skippgp --nocheck so pretty standard.
Well apparently it's not "pretty standard" as others can build it without errors.
From the build tree where ntlib.o
was built - can you manually rebuild that file (by entering the right build directory and running a make command or similar, possibly removing ntlib.o before that), and record the command that built the file. If you can rerun that, but replace options like -c -o ntlib.o
with -E -o ntlib-preprocessed.c
, then you get one single file which contains all the source that ended up included at the point. If you can provide that file, together with the exact command which is used to compile the file, together with the exact version of the compiler used to build it, then someone might be able to reproduce it and look into it.
One more thing, what is output of your gcc -v
when you call it in the subsystem that you are building for?
standard mingw64
$ gcc -v
Using built-in specs.
COLLECT_GCC=I:\Msys2\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=I:/Msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-12.2.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap --enable-checking=release --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --disable-sjlj-exceptions --with-dwarf2 --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Rev1, Built by MSYS2 project)
the TDM version
$ gcc -v
Using built-in specs.
COLLECT_GCC=I:\Msys2\tdm32\bin\gcc.exe
COLLECT_LTO_WRAPPER=I:/Msys2/tdm32/bin/../lib/gcc/i686-w64-mingw32/11.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-11.3.0/configure --prefix=/tdm32 --with-local-prefix=/tdm32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/tdm32/i686-w64-mingw32/include --libexecdir=/tdm32/lib --enable-bootstrap --enable-checking=release --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/tdm32 --with-mpfr=/tdm32 --with-mpc=/tdm32 --with-isl=/tdm32 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --enable-sjlj-exceptions --without-dwarf2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Rev2, Built by MSYS2 project)
pretty similar though i use a bit older version for the TDM compiler the lack of --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ is because the TDM version links to the static runtimes by default.
ill try doing as you suggested.
turns out the stpcpy symbol is from libgnu.a stpcpy.o _stpcpy ntlib-preprocessed.zip libgnu.zip
turns out the stpcpy symbol is from libgnu.a stpcpy.o _stpcpy ntlib-preprocessed.zip
This file isn't preprocessed source, this is an object file. You would have needed to replace the -c
option to the compiler with -E
.
Where is the source to this libgnu?
Oh, also, when preprocessing the input files, add -dD
to add even more valuable debugging info in the preprocessed output.
With those clues, I did find a discussion from 2014 about this same issue in a different form: https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02154.html
In short, the issue is the following:
stpcpy
function for systems that lack itstpcpy
function, GCC assumes (more or less correctly) that stpcpy
is available, and can transform calls from strcpy
into stpcpy
as part of an optimizationstrcpy
into __strcpy_chk
, the same GCC optimization that does strcpy
->stpcpy
probably also can change __strcpy_chk
into __stpcpy_chk
- even though there is no declaration of __stpcpy_chk
anywhere.So even if mingw-w64 itself doesn't provide stpcpy
in any form, a third party provided version of stpcpy
can trigger GCC to emit calls to __stpcpy_chk
- which used to be provided by GCC's libssp, so everything was fine. But mingw-w64-crt's ssp routines lack this function.
So if we want to practically paper over this, I guess we'll need to just bite the bullet and provide __stpcpy_chk
in mingw-w64-crt's ssp routines, just to make the transition from GCC's libssp smoother. But we shouldn't be adding the plain stpcpy
in itself IMO. WDYT @mati865 ?
@mmuetzel When you test built it, did you build it with GCC or Clang? @revelator is building it with GCC for i686, in case that changes some factors in GCC's decisions about optimizing.
So if we want to practically paper over this, I guess we'll need to just bite the bullet and provide __stpcpy_chk in mingw-w64-crt's ssp routines, just to make the transition from GCC's libssp smoother. But we shouldn't be adding the plain stpcpy in itself IMO. WDYT @mati865 ?
I'm not very fond of doing workarounds in mingw-w64 for downstream issues (IMO they should have handled the fallback differently) but if there is no other way...
Agree on stpcpy
part.
When you test built it, did you build it with GCC or Clang? @revelator is building it with GCC for i686, in case that changes some factors in GCC's decisions about optimizing.
I have built it with i686 GCC 12.2 (the one provided by MSYS2) in MINGW32 subsystem but without changing configuration. If I manually modify CLFAGS
like in https://github.com/msys2/MSYS2-packages/pull/3222 then I can reproduce the issue.
This follows https://sourceforge.net/p/mingw-w64/mailman/message/36764708/ which I think there is no solution other than disabling
-D_FORTIFY_SOURCE
.Rationale:
-lssp
(or-fstack-protector
which adds-lssp
implicitly) to work.-lssp
must be added intoLIBS
explicitly.