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

mingw-w64-qt5* 5.13.2 does not compile #105

Closed
kraxarn opened this issue Nov 11, 2019 · 10 comments
Closed

mingw-w64-qt5* 5.13.2 does not compile #105

kraxarn opened this issue Nov 11, 2019 · 10 comments
Labels

Comments

@kraxarn
Copy link
Contributor

kraxarn commented Nov 11, 2019

Had 5.13.1 installed, compilation fails when updating to 5.13.2. Error occurs with all qt5 packages I've tried (qt5-base, qt5-base-static, qt5-declarative, qt5-quickcontrols2, qt5-svg, qt5-tools). Tried clean building and even reinstalling it, but it fails with the same error:

/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qcryptographichash.o:qcryptographichash.cpp:(.text+0x12d53): undefined reference to `__memset_chk'
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qcryptographichash.o:qcryptographichash.cpp:(.text+0x14d47): undefined reference to `__memcpy_chk'
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qcryptographichash.o:qcryptographichash.cpp:(.text+0x14f2d): undefined reference to `__memcpy_chk'
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qcryptographichash.o:qcryptographichash.cpp:(.text+0x14feb): undefined reference to `__memcpy_chk'
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qcryptographichash.o:qcryptographichash.cpp:(.text+0x150f0): undefined reference to `__memcpy_chk'
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qutfcodec.o:qutfcodec.cpp:(.text+0x159e): undefined reference to `__memcpy_chk'
/usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: .obj/release/qcborvalue.o:qcborvalue.cpp:(.text+0x44bb): more undefined references to `__memcpy_chk' follow
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile.Release:1137: ../../lib/Qt5Core.dll] Error 1
make[3]: Leaving directory '/home/kraxarn/.cache/yay/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/corelib'
make[2]: *** [Makefile:38: release] Error 2
make[2]: Leaving directory '/home/kraxarn/.cache/yay/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/corelib'
make[1]: *** [Makefile:223: sub-corelib-make_first] Error 2
make[1]: Leaving directory '/home/kraxarn/.cache/yay/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src'
make: *** [Makefile:47: sub-src-make_first] Error 2

Trying to compile with yay on Manjaro, Linux 5.3.9

@Martchus
Copy link
Owner

Likely flags need to be changed similar to mingw-w64-configure to make this work with mingw-w64 7.0.0: https://aur.archlinux.org/cgit/aur.git/commit/?h=mingw-w64-configure&id=c2ee2d12aa95d15dde2f3125a75a08b1622bfb73

@Martchus Martchus added the bug label Nov 11, 2019
@Martchus
Copy link
Owner

I'll investigate the issue when I have time. In the meantime you can try to adjust the relevant lines in the PKGBUILD (see https://github.com/Martchus/PKGBUILDs/blob/master/qt5-base/mingw-w64/PKGBUILD#L157) similar to the mentioned mingw-w64-configure change. If it works, let me know (or create a PR).

@kraxarn
Copy link
Contributor Author

kraxarn commented Nov 11, 2019

The CPP flags seems to be the same (-D_FORTIFY_SOURCE=2, commit changed to 2 from 0), but the linker flags are different, so I added -fstack-protector and got a different error:

> /usr/bin/ld: -f may not be used without -shared
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:69: arch_host] Error 1
Project ERROR: Could not determine host architecture. See config.log for details.

Not sure if that's what you meant.

@Martchus
Copy link
Owner

Yes, that's what I mean. But if it doesn't work I'll have to figure something else, e.g. completely disabling fortify using -D_FORTIFY_SOURCE=0.

By the way, there's a discussion in mingw-w64-configure which also contains links to the mingw-w64 mailing list.

@xantares
Copy link
Contributor

can you retry with "-Wl,-fstack-protector" ?

@Martchus
Copy link
Owner

Martchus commented Nov 12, 2019

I've just started a rebuild with

@@ -157,7 +157,7 @@ prepare() {
   CPPFLAGS="${MINGW_CPPFLAGS:--D_FORTIFY_SOURCE=2}"
   CFLAGS="${MINGW_CFLAGS:-$CPPFLAGS -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4}"
   CXXFLAGS="${MINGW_CXXFLAGS:-$CPPFLAGS -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4}"
-  LDFLAGS="${MINGW_LDFLAGS:--Wl,-O1,--sort-common,--as-needed}"
+  LDFLAGS="${MINGW_LDFLAGS:--Wl,-O1,--sort-common,--as-needed -fstack-protector}"
   sed -i -e "s|^\(QMAKE_CFLAGS_RELEASE.*=\).*$|\1 ${CFLAGS}|" \
          -e "s|^\(QMAKE_CXXFLAGS_RELEASE.*=\).*$|\1 ${CXXFLAGS}|" \
          -e "s|^\(QMAKE_LFLAGS_RELEASE.*=\).*$|\1 ${LDFLAGS}|" \

and have already a few i686 DLLs. So just -fstack-protector generally works. Not sure what @kraxarn did wrong. I'll update the packages when I know the whole build succeeds. I suppose only mingw-w64-qt5-base (which contains the mkspec with these flags) needs to be rebuilt.

@xantares
Copy link
Contributor

can you update mingw-w64-cmake, mingw-w64-configure then ?

@Martchus
Copy link
Owner

Should be updated.

Martchus added a commit that referenced this issue Nov 12, 2019
* Prevent `undefined reference to `__memcpy_chk'`
* Be consistent with
  https://aur.archlinux.org/cgit/aur.git/commit/?h=mingw-w64-configure&id=c2ee2d12aa95d15dde2f3125a75a08b1622bfb73
* Rebuild qtdeclarative as well to check whether we can
  build dynamically and statically linked executables
* See #105
@Martchus
Copy link
Owner

It also works to build dynamically and statically linked EXEs (rebuilding qtdeclarative to test that). So I'm closing the ticket. I'll update the binary repo soon.

@kraxarn
Copy link
Contributor Author

kraxarn commented Nov 15, 2019

Tested again now and it seems to work fine, I may have forgotten to clean build or something, either way, thanks for the help.

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

No branches or pull requests

3 participants