msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.3k stars 1.22k forks source link

[RFC] Disable `_FORTIFY_SOURCE` #5803

Closed lhmouse closed 5 years ago

lhmouse commented 5 years ago

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:

  1. Unlike glibc, mingw-w64 does not provide fortified functions at all. So fortification requires -lssp (or -fstack-protector which adds -lssp implicitly) to work.
  2. libssp is part of GCC libraries which is unavailable(??) when building GCC itself.
  3. When building everything else, -lssp must be added into LIBS explicitly.
  4. For this reason it had better be removed. Prior to the change in mingw-w64 it had no effect so there is no loss by removing it.
revelator commented 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.

revelator commented 5 years ago

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.

revelator commented 5 years ago

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.

revelator commented 5 years ago

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.

lhmouse commented 5 years ago

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.

revelator commented 5 years ago

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.

lhmouse commented 5 years ago

That could also bring licensing issues. Also if libssp code ever changes how should we synchronize with the upstream?

lhmouse commented 5 years ago

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).

revelator commented 5 years ago

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.

revelator commented 5 years ago

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.

lhmouse commented 5 years ago

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.

lhmouse commented 5 years ago

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
lhmouse commented 5 years ago

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
lhmouse commented 5 years ago

New PR: https://github.com/msys2/MINGW-packages-dev/pull/6

revelator commented 5 years ago

packages still affected by this so far are libsndfile flac and ruby.

lhmouse commented 5 years ago

did -lssp (in LIBS) or -fstack-protector (in LDFLAGS) help?

revelator commented 5 years ago

with flac and libsndfile it worked but ruby will crash on every compile :/

lazka commented 2 years ago

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.

mati865 commented 2 years ago

Should we now enable it in makepkg?

lazka commented 2 years ago

Should we now enable it in makepkg?

sure, why not: https://github.com/msys2/MSYS2-packages/pull/3222

revelator commented 2 years ago

anyone else get a ton of errors in celt after this change ?

revelator commented 2 years ago

invalid use of 'builtin_va_arg_pack_len ()' invalid use of 'builtin_va_arg_pack ()'

followed by even more errors of the same kind :/

revelator commented 2 years ago

seems to be comming from these functions, mingw_callopen_warn_toomany mingw_callopen mingw_callsopen_warn_toomany mingw_callsopen

revelator commented 2 years ago

emacs also bails on me with undefined reference to `__stpcpy_chk'

lhmouse commented 2 years ago

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

mstorsjo commented 2 years ago

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.

mmuetzel commented 2 years ago

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.

revelator commented 2 years ago

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).

mmuetzel commented 2 years ago

Did you rebuild mingw-w64-crt-git (if you don't use the packaged version) after it was updated to include those symbols?

mati865 commented 2 years ago

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.

revelator commented 2 years ago

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 ).

revelator commented 2 years ago

some older libraries were left from the previous version which still linked to libssp, could those be the problem ?.

mstorsjo commented 2 years ago

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.

revelator commented 2 years ago

p.s both the original and mine fail in the same place so yeah it seems like some leftovers are kicking my butt.

revelator commented 2 years ago

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.

revelator commented 2 years ago

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.

mstorsjo commented 2 years ago

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?

revelator commented 2 years ago

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.

mstorsjo commented 2 years ago

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.

revelator commented 2 years ago

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
mstorsjo commented 2 years ago

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.

revelator commented 2 years ago

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.

mstorsjo commented 2 years ago

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.

mati865 commented 2 years ago

One more thing, what is output of your gcc -v when you call it in the subsystem that you are building for?

revelator commented 2 years ago

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.

revelator commented 2 years ago

turns out the stpcpy symbol is from libgnu.a stpcpy.o _stpcpy ntlib-preprocessed.zip libgnu.zip

mstorsjo commented 2 years ago

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.

libgnu.zip

Where is the source to this libgnu?

mstorsjo commented 2 years ago

Oh, also, when preprocessing the input files, add -dD to add even more valuable debugging info in the preprocessed output.

mstorsjo commented 2 years ago

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:

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.

mati865 commented 2 years ago

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.