search

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

[qt5] Qt 5.11.2 can't be built on clang 7.0.0 #4593

Closed mcallegari closed 2 years ago

mcallegari commented 6 years ago

Up to 5.11.1 all good. Yesterday I tried to build Qt 5.11.2 with my own flags set and build fails on qttools/qdoc with the error below. Reverted to llvm+clang 6.0.0: problem solved. Right now the current tree packages are not consistent.

make[3]: entering "/e/MINGW-packages/mingw-w64-qt5/src/i686/qttools/src/qdoc"
g++ -Wl,--gc-sections -Wl,-s -Wl,-subsystem,console -o ../../bin/qdoc.exe object_script.qdoc.Release  -LC:/msys64/mingw32/lib -Wl,--start-group -lclangAnalysis -lclangApplyReplacements -lclangARCMigrate -lclangAST -lclangASTMatchers -lclangBasic -lclangChangeNamespace -lclangCodeGen -lclangCrossTU -lclangDaemon -lclangDriver -lclangDynamicASTMatchers -lclangEdit -lclangFormat -lclangFrontend -lclangFrontendTool -lclangHandleCXX -lclangIncludeFixer -lclangIncludeFixerPlugin -lclangIndex -lclangLex -lclangMove -lclangParse -lclangQuery -lclangReorderFields -lclangRewrite -lclangRewriteFrontend -lclangSema -lclangSerialization -lclang_static -lclangStaticAnalyzerCheckers -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend -lclangTidy -lclangTidyAbseilModule -lclangTidyAndroidModule -lclangTidyBoostModule -lclangTidyBugproneModule -lclangTidyCERTModule -lclangTidyCppCoreGuidelinesModule -lclangTidyFuchsiaModule -lclangTidyGoogleModule -lclangTidyHICPPModule -lclangTidyLLVMModule -lclangTidyMiscModule -lclangTidyModernizeModule -lclangTidyMPIModule -lclangTidyObjCModule -lclangTidyPerformanceModule -lclangTidyPlugin -lclangTidyPortabilityModule -lclangTidyReadabilityModule -lclangTidyUtils -lclangTidyZirconModule -lclangTooling -lclangToolingASTDiff-lclangToolingCore -lclangToolingInclusions -lclangToolingRefactor -lfindAllSymbols -lLLVMLTO -lLLVMPasses -lLLVMObjCARCOpts -lLLVMSymbolize-lLLVMDebugInfoPDB -lLLVMDebugInfoDWARF -lLLVMMIRParser -lLLVMFuzzMutate -lLLVMCoverage -lLLVMTableGen -lLLVMDlltoolDriver -lLLVMOrcJIT -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMSparcDisassembler -lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMSparcAsmPrinter -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMLanaiDisassembler -lLLVMLanaiCodeGen -lLLVMLanaiAsmParser -lLLVMLanaiDesc -lLLVMLanaiAsmPrinter -lLLVMLanaiInfo -lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonAsmParser -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMBPFDisassembler -lLLVMBPFCodeGen -lLLVMBPFAsmParser -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMBPFAsmPrinter -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMARMUtils -lLLVMAMDGPUDisassembler -lLLVMAMDGPUCodeGen -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc -lLLVMAMDGPUInfo -lLLVMAMDGPUAsmPrinter -lLLVMAMDGPUUtils -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -lLLVMObjectYAML -lLLVMLibDriver -lLLVMOption -lLLVMWindowsManifest -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMLineEditor -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMCodeGen -lLLVMTarget -lLLVMCoroutines -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMScalarOpts -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMInstCombine -lLLVMBitWriter -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMAnalysis -lLLVMProfileData -lLLVMObject -lLLVMMCParser -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -Wl,--end-group -lz -lz3 -lgomp -lpsapi -lshell32 -lole32 -luuid -ladvapi32 -lversion -LE:/MINGW-packages/mingw-w64-qt5/src/i686/qtdeclarative/lib E:/MINGW-packages/mingw-w64-qt5/src/i686/qtdeclarative/lib/libQt5QmlDevTools.a -LE:/MINGW-packages/mingw-w64-qt5/src/i686/qtbase/lib E:/MINGW-packages/mingw-w64-qt5/src/i686/qtbase/lib/libQt5Core.dll.a
C:/msys64/mingw32/lib/libclangEdit.a: error adding symbols: Malformed archive
collect2.exe: error: ld returned 1 exit status
make[3]: *** [Makefile.Release:195: ../../bin/qdoc.exe] Error 1
make[3]: uscita dalla directory "/e/MINGW-packages/mingw-w64-qt5/src/i686/qttools/src/qdoc"
make[2]: *** [Makefile:36: release] Error 2
make[2]: uscita dalla directory "/e/MINGW-packages/mingw-w64-qt5/src/i686/qttools/src/qdoc"
make[1]: *** [Makefile:201: sub-qdoc-make_first] Error 2
make[1]: uscita dalla directory "/e/MINGW-packages/mingw-w64-qt5/src/i686/qttools/src"
make: *** [Makefile:43: sub-src-make_first] Error 2

Because the official qt5 package is overly bloated, the flags I use in PKGBUILD are:

_build_mode=-release

_with_icu=no
_with_fontconfig=yes
_with_openssl=no
_with_dbus=yes
_system_freetype=yes
_system_zlib=yes
_system_pcre=no
_system_libpng=yes
_system_libjpeg=yes
_system_harfbuzz=yes
_build_examples=no
_build_tools=yes
_build_tests=no
_make_docs=no
revelator commented 5 years ago

hmm i might have an idea why 2.29 can build it and later can not. The biggest change in 2.30 and later versions of binutils where the addition of automatic symbol versioning,

but as you can see in the link ill provide here https://bugzilla.redhat.com/show_bug.cgi?id=1599521#c9 it was not without cost.

Unfortunatly the patches to revert this behaviour are for linux and the messages are a bit different but in the end they mean exactly the same as the error we are getting, namely that the linker cannot read the symbols.

paolo-sz commented 5 years ago

I would offer to recreate them for him

Thanks @revelator, but this is not needed. I mean, finally I find a way to build everything in all the cases (using directly .o or .obj files extracted from clangEdit library) I was not commenting anymore because my way is a very dirty workaround and the discussion turned on the real issue and a way to fix it cleanly. It is also far away from my knowledge. The only contribution I can provide right now is to share my dirty workaround as a temporary solution...

revelator commented 5 years ago

Heh it also got a bit sidetracked with the ctor stuff, but yeah it would not have helped others or else i could have turned that specific task into a fulltime job hehe.

Alexpux commented 5 years ago

@revelator try to downgrade grep to 3.0

revelator commented 5 years ago

ok ?, allthough i allready fixed it using binutils-2.29. Any problems with the current version of grep ?

mati865 commented 5 years ago

@revelator

The following changes affect only MS-Windows platforms. First, the --binary (-U) option now governs whether binary I/O is used, instead of a heuristic that was sometimes incorrect. Second, the --unix-byte-offsets (-u) option now has no effect on MS-Windows too.

mcallegari commented 5 years ago

I've seen @Alexpux updated to 5.12.0. Does this problem persist or has it been fixed ? Can we close ?

Alexpux commented 5 years ago

Issue not solved, we can’t downgrade binutils because GCC 8 require at least bounties 2.30

mcallegari commented 5 years ago

Then how did you manage to create the 5.12.0 package on i686 ? Manual changes somewhere ? I'm building my minimal version right now. Let's see how it goes.

revelator commented 5 years ago

sorry been away some days, family matters. thx mati ill try that.

revelator commented 5 years ago

guess we can only hope that the next version of binutils will fix the breakage.

Alexpux commented 5 years ago

I’m manually linking qdoc for 32-bit to finish the builds

paolo-sz commented 5 years ago

my 2 cents... although my "final" workaround (extract the objs from the lib and link them instead of the static lib) is all but optimal, I guess is somehow better than a manual linking in the middle of the building flow. As I said some comments ago, I applied this patch in a different environment so I made the port in this environment and I'm running a complete build in msys... if it will goes fine I will push everything and then it will be up to you to decide to use it or not while waiting for binutils to be fixed...

mcallegari commented 5 years ago

Issue not solved, we can’t downgrade binutils because GCC 8 require at least bounties 2.30

As of yesterday, MSYS2 delivers GCC 7.4.0. So why are we fighting against a buggy binutils when it's not yet a requirement ? Can we think about this when GCC 8 lands in MSYS2 (and possibly binutils gets fixed), and in the meantime use 2.29 ?

Alexpux commented 5 years ago

@mcallegari don’t confuse between MSYS and MINGW-W64 GCC. Right now 64-bit MINGW-W64 GCC is at 8.2.1 in repo

revelator commented 5 years ago

Not sure if binutils >= 2.30 are needed for gcc-8 i just built gcc-8.2.1 with binutils-2.29 with no problems whatsoever so is this requirement for building stuff with gcc ?

Alexpux commented 5 years ago

@revelator, try to build Qt5 with GCC8 + binutils 2.29

revelator commented 5 years ago

will try in a sec.

mcallegari commented 5 years ago

try to build Qt5 with GCC8 + binutils 2.29

Should this be "try to build clang 7.0.0 with gcc 8 and binutils 2.29" ? Cause clang is the root of all evil for Qt5

Alexpux commented 5 years ago

@mcallegari no I mean what I wrote. Qt5 cannot be builded with gcc8 + binutils 2.29

revelator commented 5 years ago

ah ok so its on use that it requires binutils greater or equal than 2.30, well seems we are back to waiting for a bugfix for binutils > 2.30 or use other methods of linking in clang in the meantime.

mingwandroid commented 5 years ago

I don't have any time to look at this, but could someone use git bisect on binutils to figure out which commit broke it here? You want to minimize the qt build time of course. Is the problem suspected to be in the linker or the assembler?

revelator commented 5 years ago

as far as i could find out it seems to be the linker which causes problems, if im not mistaken its caused by some changes to the i386pe scripts. I could try to revert them to previous behaviour but i cant say if it would break anything in regards to gcc-8.

paolo-sz commented 5 years ago

I’m manually linking qdoc for 32-bit to finish the builds

@Alexpux: Waiting for binutils to get fixed, this (85704fc63fbd118041810305c00def725c9d04ca) avoids a manual link of qdoc.exe...

revelator commented 5 years ago

a hack but a neat one :) nice job.

mcallegari commented 5 years ago

@paolo-sz thanks for the patch! Is there a PR open with that change ? @Alexpux would you accept it ?

paolo-sz commented 5 years ago

@mcallegari, no there is no PR open right now, I was not sure it was really the case to open one when, I understood, the source of the issue is identified and there are some better trial ongoing with different combination of binutils. But, if you feel a PR is needed, just let me know... It will be a matter of a second...

mcallegari commented 5 years ago

@paolo-sz Yesterday I built my minimal version of 5.12.0 with your patch and it worked flawlessly I think it would make sense, even as a temporary workaround, to have it in. At least it spares us from doing manual operations in the middle of a gigantic build.

mati865 commented 2 years ago

We have Qt 5 in CLANG64 subsystem so I'm assuming it works fine nowadays. If that's not the case please open new issue with updated steps to reproduce.