Something broke - undefined reference to `__memcpy_chk' #5868
Comments
|
The suspects are binutils, crt-git and headers-git, which were updated on the interim. |
|
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... |
|
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. |
|
You need remove from build flags -D_FORTIFY_SOURCES and stack-protector flags |
|
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:
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... |
|
@MSP-Greg probably better to write to mingw-w64 mail list about this because this is recent changes in mingw-w64 runtime |
|
Somehow related to #5803, but I did not really understand the interplay between the flag 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 |
|
@lhmouse Maybe you can clarify this a bit? |
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. |
|
Well, I've just added |
|
Yes with mingw-w64 if you define Until recently, the default configuration of makepkg had |
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
|
There are many more examples, e.g. everybody who uses AX_ADD_FORTIFY_SOURCE or autotools. |
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
|
It has been my pleasure. You may close this issue yourself. |
Recent Cygwin mingw releases require linking against libssp to avoid undefined symbols. See msys2/MINGW-packages#5868 for discussion.
Recent Cygwin mingw releases require linking against libssp to avoid undefined symbols. See msys2/MINGW-packages#5868 for discussion. Fixes: axboe#881
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>
…houh not directly webkit): msys2#5868
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
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
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)
"...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
|
I'm getting this same error trying to build EDIT: Never mind, passing |
msys2/MINGW-packages#5868 Signed-off-by: Jaymala Sinha <jsinha@chef.io>
"...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
"...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
"...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
"...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
"...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
"...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
"...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
"...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
"...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
"...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
|
Possibly related. Shopify/bootsnap#321 and puma/puma#2433. I have the latest MSYS2 and
|
|
I'm trying to build opus codec and I'm getting a similar error gcc.exe (Rev6, Built by MSYS2 project) 10.2.0 This is what I've installed:
|
|
Did you try all the suggestions provided in previous comments? |
I solved my problem. Thank you |
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:
Some builds were on Appveyor, some on GH Actions.
I'm not much of c type, so any help would be appreciated...
The text was updated successfully, but these errors were encountered: