Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Something broke - undefined reference to `__memcpy_chk' #5868

Closed
MSP-Greg opened this issue Oct 18, 2019 · 19 comments
Closed

Something broke - undefined reference to `__memcpy_chk' #5868

MSP-Greg opened this issue Oct 18, 2019 · 19 comments

Comments

@MSP-Greg
Copy link
Contributor

@MSP-Greg MSP-Greg commented Oct 18, 2019

Sometime this afternoon builds broke that earlier today were fine. All are using the gcc toolchain. below is grab of the packages that were updated with the builds:

undefined reference to `__memcpy_chk'

All packages are mingw-w64-x86_64

Good build earlier today

binutils-2.32-3
headers-git-7.0.0.5524.2346384e-1
crt-git-7.0.0.5524.2346384e-1
libwinpthread-git-7.0.0.5522.977a9720-1
gcc-libs-9.2.0-2
winpthreads-git-7.0.0.5522.977a9720-1
gcc-9.2.0-2
gcc-ada-9.2.0-2
gcc-libgfortran-9.2.0-2
gcc-fortran-9.2.0-2
gcc-objc-9.2.0-2
gdb-8.3.1-1


Bad build today

binutils-2.33.1-1
headers-git-7.0.0.5546.d200317d-1
crt-git-7.0.0.5546.d200317d-1
libwinpthread-git-7.0.0.5544.15da3ce2-1
gcc-libs-9.2.0-2
winpthreads-git-7.0.0.5544.15da3ce2-1
gcc-9.2.0-2
gcc-ada-9.2.0-2
gcc-libgfortran-9.2.0-2
gcc-fortran-9.2.0-2
gcc-objc-9.2.0-2
gdb-8.3.1-1

Some builds were on Appveyor, some on GH Actions.

I'm not much of c type, so any help would be appreciated...

@oscarfv
Copy link
Contributor

@oscarfv oscarfv commented Oct 18, 2019

The suspects are binutils, crt-git and headers-git, which were updated on the interim.

@MSP-Greg
Copy link
Contributor Author

@MSP-Greg MSP-Greg commented Oct 18, 2019

Thanks. Both Appveyor & Actions don't seem too keen on updating their images, and a lot of repos just update 'toolchain', as a full update often takes longer than the CI build/test.

IOW, it would be quite a few PR's/commits to several repos to patch around the issue...

@oscarfv
Copy link
Contributor

@oscarfv oscarfv commented Oct 18, 2019

I meant that the "bad" build used newer binutils, crt-git and headers-git packages. So fixing one of those should be enough for fixing the problem.

@Alexpux
Copy link
Member

@Alexpux Alexpux commented Oct 18, 2019

You need remove from build flags -D_FORTIFY_SOURCES and stack-protector flags

@MSP-Greg
Copy link
Contributor Author

@MSP-Greg MSP-Greg commented Oct 18, 2019

@Alexpux

Thank you for the reply. The -D_FORTIFY_SOURCES=2 did exist, and I removed it. But, still having the problem. Below is the conf summary:

   * target OS:           mingw32
   * compiler:            x86_64-w64-mingw32-gcc
   * with pthread:        no
   * with coroutine:      win64
   * enable shared libs:  yes
   * dynamic library ext: so
   * CFLAGS:              ${optflags} ${debugflags} ${warnflags}
   * LDFLAGS:             -L. -pipe -s
   * DLDFLAGS:            -pipe -s \
                          -Wl,--enable-auto-image-base,--enable-auto-import \
                          $(DEFFILE)
   * optflags:            -O3 -fno-omit-frame-pointer
   * debugflags:          -g3
   * warnflags:           -Wall -Wextra -Werror=deprecated-declarations \
                          -Werror=duplicated-cond \
                          -Werror=implicit-function-declaration \
                          -Werror=implicit-int \
                          -Werror=misleading-indentation \
                          -Werror=pointer-arith -Werror=write-strings \
                          -Wimplicit-fallthrough=0 -Wmissing-noreturn \
                          -Wno-cast-function-type \
                          -Wno-constant-logical-operand -Wno-long-long \
                          -Wno-missing-field-initializers \
                          -Wno-overlength-strings \
                          -Wno-packed-bitfield-compat \
                          -Wno-parentheses-equality -Wno-self-assign \
                          -Wno-tautological-compare -Wno-unused-parameter \
                          -Wno-unused-value -Wsuggest-attribute=format \
                          -Wsuggest-attribute=noreturn -Wunused-variable

Any other suggestions? Apologies for not being more c fluent. I've been building Ruby & RubyGems on Windows for 3+ years, and I don't recall any issues like this one...

@Alexpux
Copy link
Member

@Alexpux Alexpux commented Oct 18, 2019

@MSP-Greg probably better to write to mingw-w64 mail list about this because this is recent changes in mingw-w64 runtime

@Ede123
Copy link
Contributor

@Ede123 Ede123 commented Oct 18, 2019

Somehow related to #5803, but I did not really understand the interplay between the flag _FORTIFY_SOURCE, gcc and mingw-w64 here.

For example I used this flag before (which did not cause a problem), but see the same breakeage with the mingw-w64 update. On top of that it somehow seems to depend on how gcc is built if I correctly understood that issue.

There's also talk about libssp, which is supposed to provide the missing *_chk functions. But it's unclear to me whether there are downsides (and why it's not used by default for providing _FORTIFY_SOURCE support for mingw-w64).

@Ede123
Copy link
Contributor

@Ede123 Ede123 commented Oct 18, 2019

@lhmouse Maybe you can clarify this a bit?

@MSP-Greg
Copy link
Contributor Author

@MSP-Greg MSP-Greg commented Oct 18, 2019

Somehow related to #5803, but I did not really understand the interplay between the flag _FORTIFY_SOURCE, gcc and mingw-w64 here.

I don't believe that's the issue. I think it's a change in headers-git, possibly involving string.h maybe?

I updated binutils, gcc-libs, winpthreads-git, & gcc, and two repos that had issues built fine. I forgot libwinpthread-git, I'm going to try that later...

Again, I'm not a c type, so I'm probably wrong.

@Ede123
Copy link
Contributor

@Ede123 Ede123 commented Oct 18, 2019

Well, __memcpy_chk is one of those fortified functions that are used when you define _FORTIFY_SOURCE (but apparently are not available for linking by default).

I've just added -lssp as a linker flag to link against libssp for my own project, and that seems to work as well while still using -D_FORTIFY_SOURCE=2

@lhmouse
Copy link
Contributor

@lhmouse lhmouse commented Oct 19, 2019

Yes with mingw-w64 if you define _FORTIFY_SOUECE to something greater than zero you have to link against libssp, either by adding -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does not provide fortified functions.

Until recently, the default configuration of makepkg had -D_FORTIFY_SOURCE=2 which has been removed. If projects add this themselves then they start to have to add -lssp as well. One known example is GDB.

rurban added a commit to LibreDWG/libredwg that referenced this issue Oct 19, 2019
either add -fstack-protector for -lssp to be added,
or omit adding -D_FORTIFY_SOURCE=2 to CPPFLAGS.
We do both.

see msys2/MINGW-packages#5868
@rurban
Copy link

@rurban rurban commented Oct 19, 2019

There are many more examples, e.g. everybody who uses AX_ADD_FORTIFY_SOURCE or autotools.
I just fixed it to fix this new msys2 bug.

rurban added a commit to LibreDWG/libredwg that referenced this issue Oct 19, 2019
msys2 bug with headers-git-7.0.0.5546.d200317d-1
either add -fstack-protector for -lssp to be added,
or omit adding -D_FORTIFY_SOURCE=2 to CPPFLAGS.
See msys2/MINGW-packages#5868

actually try to link it, to catch it
@MSP-Greg
Copy link
Contributor Author

@MSP-Greg MSP-Greg commented Oct 19, 2019

@lhmouse @Ede123

Thanks for the replies. I've got several things patched and working. Ruby has a single test failure that's not in its main test suite.

Hence, I'm okay to close this...

@lhmouse
Copy link
Contributor

@lhmouse lhmouse commented Oct 21, 2019

It has been my pleasure. You may close this issue yourself.

@MSP-Greg MSP-Greg closed this Oct 21, 2019
vincentkfu added a commit to vincentkfu/fio that referenced this issue Dec 13, 2019
Recent Cygwin mingw releases require linking against libssp to avoid
undefined symbols. See
msys2/MINGW-packages#5868 for discussion.
vincentkfu added a commit to vincentkfu/fio that referenced this issue Dec 16, 2019
Recent Cygwin mingw releases require linking against libssp to avoid
undefined symbols. See
msys2/MINGW-packages#5868 for discussion.

Fixes: axboe#881
vincentkfu added a commit to vincentkfu/fio that referenced this issue Dec 16, 2019
Recent Cygwin mingw releases require linking against libssp to avoid
undefined symbols.

See msys2/MINGW-packages#5868 for discussion.
msys2/MINGW-packages#5803 also contains
discussion of possibly disabling the FORTIFY_SOURCE linker flag.

Fixes: axboe#881
Signed-off-by: Vincent Fu <vincent.fu@wdc.com>
mdforbis added a commit to mdforbis/MINGW-packages that referenced this issue Dec 17, 2019
fskjdflaskjh pushed a commit to fskjdflaskjh/binutils that referenced this issue Jan 9, 2020
Recent MinGW versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
msys2/MINGW-packages#5868 (comment)

To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.

gdb/ChangeLog:

2020-01-09  Christian Biesinger  <cbiesinger@google.com>

	* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on MinGW.

Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
disigma pushed a commit to wimal-build/binutils that referenced this issue Jan 10, 2020
Recent MinGW versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
msys2/MINGW-packages#5868 (comment)

To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.

gdb/ChangeLog:

2020-01-10  Christian Biesinger  <cbiesinger@google.com>

	* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on MinGW.

Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
ksuzu46 pushed a commit to hunter-college-ossd-spr-2020/inkscape that referenced this issue Mar 6, 2020
mingw-w64 does not seem to have native support for fortification,
libssp offers it, so let's try this for now.

Not sure yet if disabling _FORTIFY_SOURCE would be better/worse.

See also
  https://sourceforge.net/p/mingw-w64/mailman/message/36764708/
  msys2/MINGW-packages#5803
  msys2/MINGW-packages#5868

(back-ported from commit 2e9679c)
mabrand added a commit to mabrand/mxe that referenced this issue Apr 7, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
@Kaos-Industries
Copy link

@Kaos-Industries Kaos-Industries commented Apr 13, 2020

I'm getting this same error trying to build libopus on Cygwin, using the mingw-64 build tools. I'm not a programmer, so for my clarification, what's the best way to get this package to successfully compile? Thank you.

EDIT: Never mind, passing CFLAGS="I=/usr/local/llsp" to configure fixed the issue.

jaymalasinha pushed a commit to chef/omnibus that referenced this issue Apr 29, 2020
mabrand added a commit to mabrand/mxe that referenced this issue May 29, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
tonytheodore added a commit to tonytheodore/mxe that referenced this issue May 30, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
tonytheodore added a commit to tonytheodore/mxe that referenced this issue Jun 5, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
tonytheodore added a commit to tonytheodore/mxe that referenced this issue Jun 5, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
tonytheodore added a commit to mxe/mxe that referenced this issue Jun 6, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
tonytheodore added a commit to mxe/mxe that referenced this issue Jun 6, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
Lord-Kamina added a commit to Lord-Kamina/mxe that referenced this issue Jun 23, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
Lord-Kamina added a commit to Lord-Kamina/mxe that referenced this issue Jun 23, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
rezahousseini pushed a commit to rezahousseini/mxe that referenced this issue Sep 9, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
rezahousseini pushed a commit to rezahousseini/mxe that referenced this issue Sep 9, 2020
   "...with mingw-w64 if you define _FORTIFY_SOUECE to something
    greater than zero you have to link against libssp, either by adding
    -fstack-protector or -lssp, because mingw-w64, unlike GNU libc, does
    not provide fortified functions."

msys2/MINGW-packages#5868
@starrychloe
Copy link

@starrychloe starrychloe commented Oct 16, 2020

Possibly related. Shopify/bootsnap#321 and puma/puma#2433. I have the latest MSYS2 and pacman shows all packages up to date (via ridk install 3). I don't think the compiler should break older projects. I think compilers should be backwards compatible.

>ridk version
---
ruby:
  path: C:/ruby24
  version: 2.4.3
  platform: x64-mingw32
ruby_installer:
  package_version: 2.4.3-1
  git_commit: 36aac73
msys2:
  path: C:\msys64
cc: x86_64-w64-mingw32-gcc (Rev4, Built by MSYS2 project) 10.2.0
sh: GNU bash, version 4.4.23(2)-release (x86_64-pc-msys)
os: Microsoft Windows [Version 6.3.9600]
MSYS2 seems to be already installed
Install MSYS2 and MINGW development toolchain ...
> pacman -S --needed --noconfirm autoconf autoconf2.13 autogen automake-wrapper automake1.10 automake1.11 automake1.12 automake1.13 automake1.14 automake1.15 automake1.6 automake1.7 automake1.8 automake1.9 diffutils file gawk grep libtool m4 make patch pkg-config sed texinfo texinfo-tex wget mingw-w64-x86_64-binutils mingw-w64-x86_64-crt-git mingw-w64-x86_64-gcc mingw-w64-x86_64-gcc-libs mingw-w64-x86_64-headers-git mingw-w64-x86_64-libmangle-git mingw-w64-x86_64-libwinpthread-git mingw-w64-x86_64-make mingw-w64-x86_64-pkg-config mingw-w64-x86_64-tools-git mingw-w64-x86_64-winpthreads-git
...
warning: mingw-w64-x86_64-winpthreads-git-8.0.0.6001.98dad1fe-3 is up to date -- skipping
 there is nothing to do
@whitequill
Copy link

@whitequill whitequill commented Jan 20, 2021

I'm trying to build opus codec and I'm getting a similar error
I am using:

gcc.exe (Rev6, Built by MSYS2 project) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This is what I've installed: pacman -S base-devel mingw-w64-x86_64-gcc mingw-w64-x86_64-gcc-fortran mingw-w64-x86_64-toolchain development

D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: celt/.libs/bands.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/.libs/decode_core.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/.libs/PLC.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/float/.libs/encode_frame_FLP.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/float/.libs/encode_frame_FLP.o:D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: more undefined references to `__memcpy_chk' follow
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/float/.libs/pitch_analysis_core_FLP.o: in function `memset':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:208: undefined reference to `__memset_chk'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:2128: libopus.la] Error 1
make[2]: Leaving directory '/home/brazg/build.opus'
make[1]: *** [Makefile:2646: all-recursive] Error 1
make[1]: Leaving directory '/home/brazg/build.opus'
make: *** [Makefile:1615: all] Error 2
make  install-recursive
make[1]: Entering directory '/home/brazg/build.opus'
make[2]: Entering directory '/home/brazg/build.opus'
  CCLD     libopus.la
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: celt/.libs/bands.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/.libs/decode_core.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/.libs/PLC.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/float/.libs/encode_frame_FLP.o: in function `memcpy':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/float/.libs/encode_frame_FLP.o:D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: more undefined references to `__memcpy_chk' follow
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: silk/float/.libs/pitch_analysis_core_FLP.o: in function `memset':
D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:208: undefined reference to `__memset_chk'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:2128: libopus.la] Error 1
make[2]: Leaving directory '/home/brazg/build.opus'
make[1]: *** [Makefile:2646: install-recursive] Error 1
make[1]: Leaving directory '/home/brazg/build.opus'
make: *** [Makefile:3202: install] Error 2

@Biswa96
Copy link
Collaborator

@Biswa96 Biswa96 commented Jan 20, 2021

Did you try all the suggestions provided in previous comments?

@whitequill
Copy link

@whitequill whitequill commented Jan 20, 2021

Did you try all the suggestions provided in previous comments?

I solved my problem. Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants