Something broke - undefined reference to `__memcpy_chk' #5868

MSP-Greg · 2019-10-18T01:49:13Z

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

The text was updated successfully, but these errors were encountered:

oscarfv · 2019-10-18T02:29:52Z

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

MSP-Greg · 2019-10-18T02:51:41Z

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 · 2019-10-18T02:56:45Z

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 · 2019-10-18T04:57:44Z

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

MSP-Greg · 2019-10-18T08:26:12Z

@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 · 2019-10-18T08:57:08Z

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

Ede123 · 2019-10-18T17:25:09Z

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 · 2019-10-18T17:28:33Z

@lhmouse Maybe you can clarify this a bit?

MSP-Greg · 2019-10-18T18:16:23Z

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 · 2019-10-18T18:20:28Z

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 · 2019-10-19T06:36:20Z

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.

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 · 2019-10-19T12:15:58Z

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.

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 · 2019-10-19T19:04:22Z

@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 · 2019-10-21T17:21:22Z

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

starrychloe · 2020-10-16T23:06:17Z

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 · 2021-01-20T09:04:29Z

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 · 2021-01-20T09:14:01Z

Did you try all the suggestions provided in previous comments?

whitequill · 2021-01-20T09:37:05Z

Did you try all the suggestions provided in previous comments?

I solved my problem. Thank you

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

Recent version of mingw need projects using `-D_FORTIFY_SOURCE` to link with `ssp`. See msys2/MINGW-packages#5868 (comment)

ref. https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5f23a08201ed01570b34f5cff99a95fc7b9e2fdb > Don't define _FORTIFY_SOURCE on MinGW > > 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.

lazka · 2022-10-10T06:59:17Z

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.

As reported in msys2/MINGW-packages#5868

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

abbf660

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

MSP-Greg closed this as completed Oct 21, 2019

Alexpux mentioned this issue Nov 1, 2019

Emacs does not build any more #5918

Closed

vincentkfu added a commit to vincentkfu/fio that referenced this issue Dec 13, 2019

Makefile: add libssp for Windows

23c6037

Recent Cygwin mingw releases require linking against libssp to avoid undefined symbols. See msys2/MINGW-packages#5868 for discussion.

glx22 mentioned this issue Dec 14, 2019

Fix: [MinGW] undefined references when _FORTIFY_SOURCE > 0 OpenTTD/OpenTTD#7860

Merged

vincentkfu added a commit to vincentkfu/fio that referenced this issue Dec 16, 2019

Makefile: add libssp for Windows

276abb9

Recent Cygwin mingw releases require linking against libssp to avoid undefined symbols. See msys2/MINGW-packages#5868 for discussion. Fixes: axboe#881

vincentkfu mentioned this issue Dec 16, 2019

Makefile: add libssp for Windows axboe/fio#882

Merged

mdforbis added a commit to mdforbis/MINGW-packages that referenced this issue Dec 17, 2019

Add patch for change to MinGW. See information found here (similiar t…

cd16567

…houh not directly webkit): msys2#5868

native-api mentioned this issue Feb 7, 2020

Undefined reference to __chk_fail' and __memcpy_chk' when compiling extensions (+solution) oneclick/rubyinstaller2#168

Closed

sumogr mentioned this issue Mar 23, 2020

[MSYS2] Fix broken lib linker sumoprojects/sumokoin#765

Merged

MaxKellermann mentioned this issue Jul 2, 2020

0.22~git does not build for Windows MusicPlayerDaemon/MPD#913

Closed

z-s-e mentioned this issue Jul 12, 2020

Fix MinGW problem xiph/opus#189

Closed

jim-wilson mentioned this issue Jul 28, 2020

ld_new.exe blocked by Bitdefender (MINGW64) for 64 bit arch riscv-software-src/riscv-tools#315

Open

kinichiro mentioned this issue Sep 8, 2020

MinGW-w64 Error libressl/portable#615

Closed

asanoic mentioned this issue Oct 1, 2020

build on GCC/MinGW-w64 using cmake xiph/flac#228

Closed

omasanori mentioned this issue Nov 4, 2020

Error while building LibreSSL using Cygwin for Windows 10 libressl/portable#637

Closed

kmilos mentioned this issue Jan 14, 2021

Build exiv2 on windows/msys2 Exiv2/exiv2#1449

Closed

kbsec mentioned this issue Feb 16, 2021

Compiling Libressl 3.3.1 on Ubuntu for Windows x86 and x64 target failes libressl/portable#649

Closed

jeremyd2019 mentioned this issue Apr 26, 2021

llvm unable to link to static libgcc #8427

Closed

mgautierfr added a commit to kiwix/kiwix-build that referenced this issue Jul 2, 2021

Link with ssp on win32.

c244e5b

Recent version of mingw need projects using `-D_FORTIFY_SOURCE` to link with `ssp`. See msys2/MINGW-packages#5868 (comment)

dylanmccall pushed a commit to dylanmccall/kiwix-build that referenced this issue Jul 20, 2021

Link with ssp on win32.

cb3f69f

Recent version of mingw need projects using `-D_FORTIFY_SOURCE` to link with `ssp`. See msys2/MINGW-packages#5868 (comment)

toots mentioned this issue Jun 15, 2022

Improvements for cross-compilation ocaml/dune#5883

Open

lucifer1004 mentioned this issue Sep 20, 2022

[gzip] Upgrade to 1.12 JuliaPackaging/Yggdrasil#5538

Merged

shawnlaffan mentioned this issue Dec 19, 2022

Summary of whats blocking perl builds? StrawberryPerl/build-extlibs#4

Closed

franko pushed a commit to lhelper-org/cairo that referenced this issue Dec 28, 2023

fix: Windows problem with FORTIFY SOURCE

2fc2887

As reported in msys2/MINGW-packages#5868

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Something broke - undefined reference to `__memcpy_chk' #5868

Something broke - undefined reference to `__memcpy_chk' #5868

MSP-Greg commented Oct 18, 2019

oscarfv commented Oct 18, 2019

MSP-Greg commented Oct 18, 2019

oscarfv commented Oct 18, 2019

Alexpux commented Oct 18, 2019

MSP-Greg commented Oct 18, 2019 •

edited

Alexpux commented Oct 18, 2019

Ede123 commented Oct 18, 2019 •

edited

Ede123 commented Oct 18, 2019

MSP-Greg commented Oct 18, 2019

Ede123 commented Oct 18, 2019 •

edited

lhmouse commented Oct 19, 2019

rurban commented Oct 19, 2019

MSP-Greg commented Oct 19, 2019

lhmouse commented Oct 21, 2019

starrychloe commented Oct 16, 2020 •

edited

whitequill commented Jan 20, 2021 •

edited

Biswa96 commented Jan 20, 2021

whitequill commented Jan 20, 2021 •

edited

lazka commented Oct 10, 2022

Something broke - undefined reference to `__memcpy_chk' #5868

Something broke - undefined reference to `__memcpy_chk' #5868

Comments

MSP-Greg commented Oct 18, 2019

oscarfv commented Oct 18, 2019

MSP-Greg commented Oct 18, 2019

oscarfv commented Oct 18, 2019

Alexpux commented Oct 18, 2019

MSP-Greg commented Oct 18, 2019 • edited

Alexpux commented Oct 18, 2019

Ede123 commented Oct 18, 2019 • edited

Ede123 commented Oct 18, 2019

MSP-Greg commented Oct 18, 2019

Ede123 commented Oct 18, 2019 • edited

lhmouse commented Oct 19, 2019

rurban commented Oct 19, 2019

MSP-Greg commented Oct 19, 2019

lhmouse commented Oct 21, 2019

starrychloe commented Oct 16, 2020 • edited

whitequill commented Jan 20, 2021 • edited

Biswa96 commented Jan 20, 2021

whitequill commented Jan 20, 2021 • edited

lazka commented Oct 10, 2022

MSP-Greg commented Oct 18, 2019 •

edited

Ede123 commented Oct 18, 2019 •

edited

Ede123 commented Oct 18, 2019 •

edited

starrychloe commented Oct 16, 2020 •

edited

whitequill commented Jan 20, 2021 •

edited

whitequill commented Jan 20, 2021 •

edited