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
Alexpux commented 6 years ago

@mcallegari yes I see clang linking errors when building 32 bit Qt5, for 64 bit all is fine. I dont know how to resolve it. There are a lot of issues for 32-bit last time. I dont have time to fix all of this.

oscarfv commented 6 years ago

@mcallegari :The shown command is using g++ for linking. Is that expected?

mcallegari commented 6 years ago

@oscarfv I think so. A .a file is just an archive of .o files, created with the ar tool. g++ can invoke other tools as well, in fact the error is actually returned by ld, which is part of the linking stage.

revelator commented 6 years ago

Yep seing this as well, rebuilding LLVM+Clang does not fix it unfortunatly.

paolo-sz commented 6 years ago

I solved by moving -lclangEdit after -lclangFrontend (qttools/mkspecs/features/qt_find_clang.prf) linker's black magic...

Seriously, libclangEdit seems to have no issue at all by itself, proof is the workaround above and also that if I run the failing command replacing the -lclangEdit with /libclangEdit.a (or maybe the shared version), the errors goes away... I fear a bug in the linker...

mcallegari commented 6 years ago

@paolo-sz nice finding! Can you please submit a PR to @Alexpux to adjust https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-qt5/0052-qt-5.11-mingw-fix-link-qdoc-with-clang.patch ? Thanks

Alexpux commented 6 years ago

@paolo-sz @mcallegari patch not helps. I still get error on 32 bit

paolo-sz commented 5 years ago

@Alexpux you are right... don't know what happened but with a clean msys2 install I also see the error again... the only way to make it disappear is to replace -lclangEdit with /mingw32/lib/libclangEdit.a

but this means the 0052... patch need to be fixed a lot in order to support both 64 and 32 bit version...

mcallegari commented 5 years ago

Maybe 2 distinct patches ? @Alexpux is there a way in PKGBUILD to distinguish if a build is 32 or 64 bit ?

paolo-sz commented 5 years ago

Maybe easier than I was expecting... by using $$clangInstallDir/lib/libclangEdit.a

But maybe it is too harsh to link directly to the library (static)... I'm not sure this is feasible... I mean, I have no knowledge on the availability of the clangEdit static library in all the possible compiling scenario. Maybe @Alexpux can better judge if this change is feasible.

revelator commented 5 years ago

I can build shared qt with this patch but the static qt dies with the same error even with this patch.

paolo-sz commented 5 years ago

@revelator, you are right, the static build dies while compiling qdoc but with another error, not the "maformed archive" one but, instead, H:/MINGW-packages/mingw-w64-qt5-static/pkg/mingw-w64-i686-qt5-static/mingw32/qt5-static/lib/libQt5Core.dll.a: No such file or directory. This seems to be something related to MSYS2 install or qt-static itself... unfortunately all this stuff takes hours to compile...

paolo-sz commented 5 years ago

Sigh... my pc should be completely rotten... another try and I got back the malformed archive error...

revelator commented 5 years ago

i have a hunch that it might be picking up the static libclang archive instead of the shared one, not the first time this has happened. Going to do an experiment and removing the static libclang.a to see what happens.

revelator commented 5 years ago

or rather they get mixed up, so that the static libclangedit gets linked to the dynamic one and vice versa. One peculiar thing, the static libraries have msvc style object formats (.obj) while the dynamic ones do not (.o) are the static ones built with clang itself ?.

paolo-sz commented 5 years ago

I did some experiment too... this time the only way to get qdoc.exe correctly linked is to extract the .obj files from the static clangEdit library (ar -x libclangEdit.a) and to link them instead of the library file... but this should be the worst dirty hack I ever seen... But I'm getting more and more convinced we are fighting against a bug within the linker or the ranlib/ar pair...

revelator commented 5 years ago

i seen that particular bug mentioned at the binutils bugzilla, unfortunatly it was rejected as ther maintainer could not reproduce it, and it seems to be spurious at best as to when it happens.

Come to think of it, there has been mention that ld does not handle clang libraries correctly and a proposed patch. Let me see if i can find it again.

revelator commented 5 years ago

Well here is something interresting, while experimenting i tried making a build of clang with ar and ranlib forced to use the ones from binutils.

old build threw an error in my face when i tried to run nm on libclangedit.a which led me to belive that it might not have been created by ar in the first place but the new one with ar and ranlib forced worked as you can see here ->

''' Commit.cpp.obj: 00000000 b .bss 00000000 d .data 00000000 r .rdata 00000000 r .rdata$zzz 00000000 t .text U llvm::SmallVectorBase::grow_pod(void, unsigned int, unsigned int) U llvm::report_bad_alloc_error(char const, bool) U clang::edit::EditedSource::canInsertInOffset(clang::SourceLocation, clang::edit::FileOffset) 00000f00 T clang::edit::Commit::insertWrap(llvm::StringRef, clang::CharSourceRange, llvm::StringRef) 000019e0 T clang::edit::Commit::replaceText(clang::SourceLocation, llvm::StringRef, llvm::StringRef) 00000f90 T clang::edit::Commit::canRemoveRange(clang::CharSourceRange, clang::edit::FileOffset&, unsigned int&) 00001930 T clang::edit::Commit::canReplaceText(clang::SourceLocation, llvm::StringRef, clang::edit::FileOffset&, unsigned int&) 000014b0 T clang::edit::Commit::insertFromRange(clang::SourceLocation, clang::CharSourceRange, bool, bool) 000016b0 T clang::edit::Commit::replaceWithInner(clang::CharSourceRange, clang::CharSourceRange) 00000780 T clang::edit::Commit::canInsertInOffset(clang::SourceLocation, clang::edit::FileOffset) 00000590 T clang::edit::Commit::addInsertFromRange(clang::SourceLocation, clang::edit::FileOffset, clang::edit::FileOffset, unsigned int, bool) 00000ae0 T clang::edit::Commit::canInsertAfterToken(clang::SourceLocation, clang::edit::FileOffset&, clang::SourceLocation&) 00000e30 T clang::edit::Commit::insert(clang::SourceLocation, llvm::StringRef, bool, bool) 00001620 T clang::edit::Commit::remove(clang::CharSourceRange) 00001810 T clang::edit::Commit::replace(clang::CharSourceRange, llvm::StringRef) 000002d0 T clang::edit::Commit::addInsert(clang::SourceLocation, clang::edit::FileOffset, llvm::StringRef, bool) 00000690 T clang::edit::Commit::addRemove(clang::SourceLocation, clang::edit::FileOffset, unsigned int) 000007f0 T clang::edit::Commit::canInsert(clang::SourceLocation, clang::edit::FileOffset&) 00000230 T clang::edit::Commit::Commit(clang::edit::EditedSource&) 00000230 T clang::edit::Commit::Commit(clang::edit::EditedSource&) U clang::Lexer::makeFileCharRange(clang::CharSourceRange, clang::SourceManager const&, clang::LangOptions const&) U clang::Lexer::MeasureTokenLength(clang::SourceLocation, clang::SourceManager const&, clang::LangOptions const&) U clang::Lexer::getLocForEndOfToken(clang::SourceLocation, unsigned int, clang::SourceManager const&, clang::LangOptions const&) U clang::Lexer::isAtEndOfMacroExpansion(clang::SourceLocation, clang::SourceManager const&, clang::LangOptions const&, clang::SourceLocation) U clang::Lexer::isAtStartOfMacroExpansion(clang::SourceLocation, clang::SourceManager const&, clang::LangOptions const&, clang::SourceLocation) U clang::SourceManager::getBufferData(clang::FileID, bool) const U clang::SourceManager::getFileIDSlow(unsigned int) const U clang::SourceManager::loadSLocEntry(unsigned int, bool) const U clang::SourceManager::getTopMacroCallerLoc(clang::SourceLocation) const U clang::SourceManager::getFileCharacteristic(clang::SourceLocation) const U clang::SourceManager::getSpellingLocSlowCase(clang::SourceLocation) const U clang::PPConditionalDirectiveRecord::findConditionalDirectiveRegionLoc(clang::SourceLocation) const U clang::PPConditionalDirectiveRecord::rangeIntersectsConditionalDirective(clang::SourceRange) const 00001b00 T clang::edit::Commit::isAtEndOfMacroExpansion(clang::SourceLocation, clang::SourceLocation) const 00001ad0 T clang::edit::Commit::isAtStartOfMacroExpansion(clang::SourceLocation, clang::SourceLocation) const 000000b0 T clang::edit::Commit::Edit::getFileRange(clang::SourceManager&) const 00000000 T clang::edit::Commit::Edit::getFileLocation(clang::SourceManager&) const 00000170 T clang::edit::Commit::Edit::getInsertFromRange(clang::SourceManager&) const U malloc U memcmp U memmove

EditedSource.cpp.obj: 00000000 b .bss 00000000 d .data 00000000 r .rdata 00000000 r .rdata$_ZTVN5clang4edit13EditsReceiverE 00000000 r .rdata$zzz 00000000 t .text 00000000 t .text$_ZNSt8_Rb_treeIN5clang4edit10FileOffsetESt4pairIKS2_NS1_12EditedSource8FileEditEESt10_Select1stIS7_ESt4lessIS2_ESaIS7_EE24_M_get_insert_uniqueposERS4 00000000 t .text$_ZNSt8_Rb_treeIN5clang4edit10FileOffsetESt4pairIKS2_NS1_12EditedSource8FileEditEESt10_Select1stIS7_ESt4lessIS2_ESaIS7_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS7ERS4 00000000 t .text$_ZNSt8_Rb_treeIN5clang4edit10FileOffsetESt4pairIKS2_NS1_12EditedSource8FileEditEESt10_Select1stIS7_ESt4lessIS2_ESaIS7_EE8_M_eraseEPSt13_Rb_tree_nodeIS7_E 00000000 t .text$_ZSt9find_ifIPN5clang4edit12EditedSource11MacroArgUseEN9__gnu_cxx5ops16_Iter_equals_valIKS3_EEET_SA_SA_T0_St26random_access_iterator_tag U cxa_pure_virtual U operator delete(void) 00000040 t canBeJoined(char, char, clang::LangOptions const&) 00000090 t applyRewrite(clang::edit::EditsReceiver&, llvm::StringRef, clang::edit::FileOffset, unsigned int, clang::SourceManager const&, clang::LangOptions const&, bool) U llvm::StringMapImpl::RehashTable(unsigned int) U llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) U llvm::SmallVectorBase::grow_pod(void, unsigned int, unsigned int) U llvm::report_bad_alloc_error(char const, bool) U clang::IdentifierInfo::IdentifierInfo() 000008b0 T clang::edit::EditedSource::copyString(llvm::Twine const&) 00001e80 T clang::edit::EditedSource::commitInsert(clang::SourceLocation, clang::edit::FileOffset, llvm::StringRef, bool) 00002890 T clang::edit::EditedSource::commitRemove(clang::SourceLocation, clang::edit::FileOffset, unsigned int) 00000b70 T clang::edit::EditedSource::applyRewrites(clang::edit::EditsReceiver&, bool) 00001260 T clang::edit::EditedSource::clearRewrites() 00000e70 T clang::edit::EditedSource::getSourceText(clang::edit::FileOffset, clang::edit::FileOffset, bool&) 00001340 T clang::edit::EditedSource::finishedCommit() 000008a0 T clang::edit::EditedSource::startingCommit() 00000fe0 T clang::edit::EditedSource::canInsertInOffset(clang::SourceLocation, clang::edit::FileOffset) 00000f70 T clang::edit::EditedSource::getActionForOffset(clang::edit::FileOffset) 00002330 T clang::edit::EditedSource::commitInsertFromRange(clang::SourceLocation, clang::edit::FileOffset, clang::edit::FileOffset, unsigned int, bool) 000003b0 T clang::edit::EditedSource::deconstructMacroArgLoc(clang::SourceLocation, clang::SourceLocation&, clang::edit::EditedSource::MacroArgUse&) 00002b30 T clang::edit::EditedSource::commit(clang::edit::Commit const&) 00000000 T clang::edit::EditsReceiver::remove(clang::CharSourceRange) U clang::Lexer::getSpelling(clang::SourceLocation, llvm::SmallVectorImpl&, clang::SourceManager const&, clang::LangOptions const&, bool) U clang::Lexer::getSourceText(clang::CharSourceRange, clang::SourceManager const&, clang::LangOptions const&, bool) U clang::Lexer::GetBeginningOfToken(clang::SourceLocation, clang::SourceManager const&, clang::LangOptions const&) U clang::Lexer::isIdentifierBodyChar(char, clang::LangOptions const&) U clang::charinfo::InfoTable U llvm::Twine::toVector(llvm::SmallVectorImpl&) const U clang::SourceManager::getBufferData(clang::FileID, bool) const U clang::SourceManager::loadSLocEntry(unsigned int, bool) const U clang::SourceManager::isMacroArgExpansion(clang::SourceLocation, clang::SourceLocation) const U clang::SourceManager::isMacroBodyExpansion(clang::SourceLocation) const U clang::SourceManager::getSpellingLocSlowCase(clang::SourceLocation) const U clang::SourceManager::getImmediateExpansionRange(clang::SourceLocation) const 000027c0 t std::_Rb_tree_iterator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > std::_Rb_tree<clang::edit::FileOffset, std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>, std::_Select1st<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::less, std::allocator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > >::_M_insertunique<std::pair<clang::edit::FileOffset, clang::edit::EditedSource::FileEdit>, std::_Rb_tree<clang::edit::FileOffset, std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>, std::_Select1st<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::less, std::allocator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > >::_Alloc_node>(std::_Rb_tree_const_iterator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::pair<clang::edit::FileOffset, clang::edit::EditedSource::FileEdit>&&, std::_Rb_tree<clang::edit::FileOffset, std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>, std::_Select1st<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::less, std::allocator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > >::_Alloc_node&) [clone .isra.96] [clone .constprop.99] 00000000 T std::_Rb_tree<clang::edit::FileOffset, std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>, std::_Select1st<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::less, std::allocator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > >::_M_get_insert_unique_pos(clang::edit::FileOffset const&) 00000000 T std::_Rb_tree<clang::edit::FileOffset, std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>, std::_Select1st<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::less, std::allocator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, clang::edit::FileOffset const&) 00000000 T std::_Rb_tree<clang::edit::FileOffset, std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit>, std::_Select1st<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >, std::less, std::allocator<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> > >::_M_erase(std::_Rb_tree_node<std::pair<clang::edit::FileOffset const, clang::edit::EditedSource::FileEdit> >) U operator new(unsigned int) U std::_Rb_tree_decrement(std::_Rb_tree_node_base) U std::_Rb_tree_increment(std::_Rb_tree_node_base) U std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base, std::_Rb_tree_node_base&) U std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base, std::_Rb_tree_node_base, std::_Rb_tree_node_base&) 00000000 T clang::edit::EditedSource::MacroArgUse std::__find_if<clang::edit::EditedSource::MacroArgUse, gnu_cxx::ops::_Iter_equals_val >(clang::edit::EditedSource::MacroArgUse, clang::edit::EditedSource::MacroArgUse, __gnu_cxx::ops::_Iter_equals_val, std::random_access_iterator_tag) 00000000 R vtable for clang::edit::EditsReceiver U free U malloc U memcpy U memmove U strlen

RewriteObjCFoundationAPI.cpp.obj: 00000000 b .bss 00000000 d .data 00000000 r .rdata 00000000 r .rdata$zzz 00000000 t .text 00000000 t .text$_ZN4llvm23SmallVectorTemplateBaseIPKN5clang4ExprELb1EE9pushbackERKS4 00000000 t .text$_ZN5clang4edit6Commit16replaceWithInnerENS11SourceRangeES2 U operator delete U operator delete(void) 00000100 t objectifyExpr(clang::Expr const, clang::edit::Commit&) 00001670 t getNSArrayObjects(clang::Expr const, clang::NSAPI const&, llvm::SmallVectorImpl<clang::Expr const>&) [clone .constprop.210] 00000b30 t rewriteToBoolLiteral(clang::ObjCMessageExpr const, clang::Expr const, clang::NSAPI const&, clang::edit::Commit&) 00000270 t checkForLiteralCreation(clang::ObjCMessageExpr const, clang::IdentifierInfo&, clang::LangOptions const&) [clone .constprop.211] 00000030 t maybePutParensOnReceiver(clang::Expr const, clang::edit::Commit&) 00000440 t canRewriteToSubscriptSyntax(clang::ObjCInterfaceDecl const&, clang::ObjCMessageExpr const, clang::ASTContext&, clang::Selector) 00000320 t rewriteToSubscriptGetCommon(clang::ObjCMessageExpr const, clang::edit::Commit&) [clone .part.189] 000006c0 t rewriteToNumericBoxedExpression(clang::ObjCMessageExpr const, clang::NSAPI const&, clang::edit::Commit&) [clone .part.193] 00000c40 t doRewriteToUTF8StringBoxedExpressionHelper(clang::ObjCMessageExpr const, clang::NSAPI const&, clang::edit::Commit&) U llvm::SmallVectorBase::grow_pod(void, unsigned int, unsigned int) 00000000 T llvm::SmallVectorTemplateBase<clang::Expr const, true>::push_back(clang::Expr const const&) U llvm::APInt::initSlowCase(unsigned long long, bool) U llvm::APInt::APInt(unsigned int, unsigned int, unsigned long long const) U clang::ASTContext::isSentinelNullExpr(clang::Expr const) U clang::DiagnosticIDs::getCustomDiagID(clang::DiagnosticIDs::Level, llvm::StringRef) U clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) 00001860 T clang::edit::rewriteToObjCLiteralSyntax(clang::ObjCMessageExpr const, clang::NSAPI const&, clang::edit::Commit&, clang::ParentMap const) 00001030 T clang::edit::rewriteToObjCSubscriptSyntax(clang::ObjCMessageExpr const, clang::NSAPI const&, clang::edit::Commit&) 00000e80 T clang::edit::rewriteObjCRedundantCallWithLiteral(clang::ObjCMessageExpr const, clang::NSAPI const&, clang::edit::Commit&) U clang::edit::Commit::insertWrap(llvm::StringRef, clang::CharSourceRange, llvm::StringRef) U clang::edit::Commit::insertFromRange(clang::SourceLocation, clang::CharSourceRange, bool, bool) 00000000 T clang::edit::Commit::replaceWithInner(clang::SourceRange, clang::SourceRange) U clang::edit::Commit::replaceWithInner(clang::CharSourceRange, clang::CharSourceRange) U clang::edit::Commit::insert(clang::SourceLocation, llvm::StringRef, bool, bool) U clang::edit::Commit::remove(clang::CharSourceRange) U clang::edit::Commit::replace(clang::CharSourceRange, llvm::StringRef) U clang::Expr::IgnoreParens() U clang::Expr::IgnoreParenCasts() U clang::Expr::IgnoreParenImpCasts() U clang::Lexer::getSourceText(clang::CharSourceRange, clang::SourceManager const&, clang::LangOptions const&, bool) U clang::QualType::getSplitUnqualifiedTypeImpl(clang::QualType) U clang::Selector::getMethodFamilyImpl(clang::Selector) U llvm::APInt::countLeadingZerosSlowCase() const U clang::ASTContext::getTypeInfo(clang::Type const) const U clang::ASTContext::getObjCIdDecl() const U clang::ASTContext::getDiagnostics() const U clang::ASTContext::getArrayDecayedType(clang::QualType) const U clang::ASTContext::getTypeDeclTypeSlow(clang::TypeDecl const) const U clang::ASTContext::getObjContainingInterface(clang::NamedDecl const) const U clang::ObjCMethodDecl::getMethodFamily() const U clang::ObjCMessageExpr::getSelector() const U clang::ObjCMessageExpr::getReceiverInterface() const U clang::ObjCInterfaceDecl::lookupMethod(clang::Selector, bool, bool, bool, clang::ObjCCategoryDecl const) const U clang::Decl::getAvailability(std::__cxx11::basic_string<char, std::char_traits, std::allocator >, llvm::VersionTuple, llvm::StringRef) const U clang::Expr::getExprLoc() const U clang::Stmt::getBeginLoc() const U clang::Stmt::getSourceRange() const U clang::Stmt::getEndLoc() const U clang::Type::isFloatingType() const U clang::Type::isSignedIntegerType() const U clang::Type::getUnqualifiedDesugaredType() const 00000000 t clang::ObjCObjectType const clang::Type::getAs() const [clone .part.91] U clang::NSAPI::getNSClassId(clang::NSAPI::NSClassIdKindKind) const U clang::NSAPI::isObjCEnumerator(clang::Expr const, llvm::StringRef, clang::IdentifierInfo&) const U clang::NSAPI::getOrInitSelector(llvm::ArrayRef, clang::Selector&) const U clang::NSAPI::getNSArraySelector(clang::NSAPI::NSArrayMethodKind) const U clang::NSAPI::getNSStringSelector(clang::NSAPI::NSStringMethodKind) const U clang::NSAPI::getNSDictionarySelector(clang::NSAPI::NSDictionaryMethodKind) const U clang::NSAPI::getNSNumberLiteralSelector(clang::NSAPI::NSNumberLiteralMethodKind, bool) const U clang::NSAPI::getNSNumberLiteralMethodKind(clang::Selector) const U clang::ParentMap::getParentIgnoreParenCasts(clang::Stmt) const U free '''

revelator commented 5 years ago

heres what works, but its a mess. ar -x libclangEdit.a && rm -f libclangEdit.a && ar rcs libclangEdit.a Commit.cpp.obj EditedSource.cpp.obj RewriteObjCFoundationAPI.cpp.obj

this creates a new static library with the correct offsets. The old one was build with llvm-ar.exe which is why ld croaks.

paolo-sz commented 5 years ago

Great finding! now the question is, shall we go ahead by patching qt builds (add some lines of code that does what you suggest in PKGBUILD file is very easy) or, maybe better, shall we patch the llvm/clang build in order to generate the "correct" library?

revelator commented 5 years ago

it would probably be better to fix this in the clang package :), not sure any other packages use libclangEdit atm, but it would be nice to not run into this again if some future packages should happen to use this. Might also be prudent to alert the clang devs that something is causing this specific library to be linked by the llvm tools instead of the native tools it is built with.

mati865 commented 5 years ago

Llvm-ar should produce correct libraries for MinGW, maybe one of the patches broke it?

paolo-sz commented 5 years ago

Before moving to the environment we are discussing, I compiled qt and llvm/clang in a complete different environment and also there I faced the malformed archive issue... There the libclangEdit library was built with the following:

/usr/bin/i686-w64-mingw32-ar.exe qc ../../../../lib/libclangEdit.a CMakeFiles/clangEdit.dir/Commit.cpp.o CMakeFiles/clangEdit.dir/EditedSource.cpp.o CMakeFiles/clangEdit.dir/RewriteObjCFoundationAPI.cpp.o /usr/bin/i686-w64-mingw32-ranlib.exe ../../../../lib/libclangEdit.a

so the library was not built by the llvm-ar... but the issue is still there...

@revelator said he uses "rcs" for ar command (which is different from the "qc" I see in my own external build) but, more suspicious, the "original" build runs ranlib too...

revelator commented 5 years ago

ar uses qc ? so it just quick adds those object files to the end of the archive ?. Not sure why that would break anything, the s switch to ar does just the same as running ranlib on the library, c just turns of a warning about the library being created and the r switch could probably be skipped completely since im recreating the library and not adding objects to an existing one. so "ar cs" should be sufficient.

I was assuming it was created by llvm-ar because the original library could not be read by nm untill recreated.

The recreated one does work however color me puzzled :/

revelator commented 5 years ago

successfully build both static and dynamic qt5 with the recreated libclangEdit.a library, and it works :). But it would be nice to find out why this specific library goes corrupt in the first place. One thing i find weird is that you report ar as using the qc flag ?, if i look at the default flags for binutils from cmakes modules it should be rc for C mode and r for C++, the s switch does not seem to be used by cmake i guess thats why it runs ranlib by default, but i see no qc flags anywhere in the modules huh ?!?. Would be rather funny if this flag is what is causing all this headache, so next experiment would be to recreate libclangEdit.a with "ar qc" and see what happens.

paolo-sz commented 5 years ago

ar qc ar qcs ar rcs ar rc ar qc followed by ranlib ar rc followed by ranlib

all produce a file with same size and a very little binary difference (few bytes in front of each binary file included in the archive which I suppose it is only a timestamp). The original file is "nicely" of a different size... :-(

revelator commented 5 years ago

guess this will be some bughunt then unless alex might have a clue as to what happens ?. did you try building qt with the recreated library ?, even though im not sure if its going to help much it would be interessting to see if the same bug pops up if the recreated library was created with the qc switch.

paolo-sz commented 5 years ago

did you try building qt with the recreated library ?

running... but it takes a loooot of time...

even though im not sure if its going to help much it would be interessting to see if the same bug pops up if the recreated library was created with the qc switch.

As I said, qc generates a file with no meaningful differences from rcs...

Curious is that ranlib does not change the recreated library... I was expecting some addition (the index) at the beginning or at the end of the file....

paolo-sz commented 5 years ago

ar qc ar qcs ar rcs ar rc ar qc followed by ranlib ar rc followed by ranlib

all produce a file with same size and a very little binary difference (few bytes in front of each binary file included in the archive which I suppose it is only a timestamp). The original file is "nicely" of a different size... :-(

Sorry, took the wrong .a file :-( ...

revelator commented 5 years ago

debugging huge projects like qt takes a load of time, a reduced testcase would be nice :) but im not aware of any other packages that use this library yet. ranlib should create an index containing the symbols from those object files, i got the same results you do so either ranlib does not do what it is supposed to (hard to believe), or something else mucks up the build process.

Running ranlib on the bad library does not fix it here either only recreating the library works. Ill incorporate a small hack in the clang PKGBUILD to automate recreating the bad library for now, but lets see if we can find the real culprit in the meantime :).

mati865 commented 5 years ago

Binutils 2.31 were reverted because clang package wasn't building with it. Maybe 2.30 version is buggy as well?

paolo-sz commented 5 years ago

Did this below in PKGBUILD file (end of prepare function) and then used the recreated qt_libclangEdit.a while linking qdoc.

No way, same malformed archive error...

  local _MINGW_DIR=
   case ${CARCH} in
     i686*)
      _MINGW_DIR="mingw32"
    ;;
    x86_64*)
      _MINGW_DIR="mingw64"
    ;;
  esac
  _clangeditobjs=\"`ar t \/${_MINGW_DIR}/lib/libclangEdit.a`"
  _clangeditobjs=`echo ${_clangeditobjs} | tr -dc '[[:print:]]'`
  ar x /${_MINGW_DIR}/lib/libclangEdit.a
  ar rcs ${CARCH}/qttools/src/qdoc/qt_libclangEdit.a ${_clangeditobjs}
  rm ${_clangeditobjs}
mcallegari commented 5 years ago

When I first submitted this issue, I had the impression this was not a Qt issue. In fact, my quick workaround was to revert to clang 6, which most likely has been built with another gcc version. So the point is, are we sure this is not because of the current gcc version provided ? Has anyone tried to build clang+qt with a more recent or an older version of gcc ? In general, MSYS2 tends to always provide the latest version of everything, but not always "latest" means "better". In my job, changing toolchain makes me sweat the hell out of me, so I don't do it THAT frequently like MSYS2 do.

revelator commented 5 years ago

hmm im using gcc-7.3.0 because its more stable than 8 but even i got the bug. So did i just get lucky with the recreated version ?. Ok next try ill revert to an earlier binutils to see if its the same bug there, if its not then as you say it might actually be a tool problem.

revelator commented 5 years ago

reverted binutils to 2.29 going to do a full build of qt5 in a sec to see if it changes anything.

revelator commented 5 years ago

paolo, you should probably move your script to an install script instead of in the prepare section, else you would just recreate the installed version and then be overwriting it with the bad one when clang installs. but qt is building atm using an earlier binutils, ill post if it changes anything.

revelator commented 5 years ago

oh hell binutils-2.30 was the version that introduced a bug in __CTOR_LIST__ :s i just noticed this cause the same binutils version is used in msys2 but has this wrong behaviour patched out which the mingw64 version does not.

And qt5 builds fine with binutils-2.29 -> later versions as it seems do not work correctly (2.30 breaks qt and 2.31 breaks clang). Not sure why my recreated library worked but i suggest reverting binutils to 2.29 untill a newer stable version.

mati865 commented 5 years ago

Is binutils 2.31 issue reported upstream?

revelator commented 5 years ago

not sure tbh, but i can file a report to them if nessesary.

Alexpux commented 5 years ago

@revelator @mati865 as Iremember not long time ago there are patches for CTOR_LIST in mingw-w64 sources, so probably something was broken there?

revelator commented 5 years ago

aye i remember the same, not sure if they where removed intentionally or if it was an oversight by alex when he reverted to binutils-2.30 from the 2.31 version. The msys2 version has them so it should be easy to recreate the PKGBUILD.

revelator commented 5 years ago

hmm https://sourceforge.net/p/mingw-w64/mailman/message/35982084/

has some explanation about why the new ctor lists where reverted, it seems to have been an experimental feature which newer worked correctly since it was newer reimplemented again. Also has me thinking that since we still have this in the msys2 crosscompiler then things might not allways work as expected.

mati865 commented 5 years ago

Mingw-builds binutils have the same patches as MSYS2 mingw-w64 binutils: https://github.com/niXman/mingw-builds/commit/afe44c3e90a6cf02d4e815302ef820fe68c8cac8#diff-415ac11b94489b4410c6d35d8a01e34f

revelator commented 5 years ago

i was refering to the msys2 crosscompiler in /opt which does have this patch. could try a build with the patchsets from the msys2 crosscompiler binutils and see if they fix things properly.

mati865 commented 5 years ago

I don't understand. All three packages (mingw-builds, MSYS2 cross, MSYS2 mingw) use the same patch for binutils 2.30 bug.

revelator commented 5 years ago

odd it was missing earlier so i did a git pull and now its there. But if that is the case then something else in that version must be broken, cause i still cannot build qt with it without jumping through hoops.

revelator commented 5 years ago

Heh i must have been tired, i just noticed that as alex says there where patches against mingw-w64 for that CTOR mess, but these patches are no longer in the mingw-w64 packages only in the one used by the msys2 crosscompiler "0005-handle-ctor_list-internally.patch", in these packages mingw-w64-cross-crt-git and mingw-w64-cross-headers-git. Not sure if it breaks anything for the crosscompiler since i assume its only used for building the msys2 runtime, still it might be a good idea to remove them there also. Guess ill have to have a look at commits from binutils-2.29 to 2.30 to see what else was changed that might cause this.

revelator commented 5 years ago

Wait a second... that patch is used if the crt is built with clang ?!? never mind then.

Alexpux commented 5 years ago

@revelator I mean that CTOR_LIST patches was already in mingw-w64 runtime. For example - https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ccda8b5229e428a6fa7036140778b23d11b554e8 As I remember there are a bunch of patches about it

revelator commented 5 years ago

Aye seems they are trying to get it working for clang :), i was refering to locally i had no idea they went ahead with the changes to CTOR_LIST so i got a little confused if you ment if it was locally or in the sources. Thats why i said newer mind since i discovered otherwise at that point.

Atleast we can rule that possibility out then i think.

Kinda strange though that i can get qt building if i recreate libclangEdit.a with binutils-2.30 but it fails for paolo, not sure what is going on there ?.

I would offer to recreate them for him, but if im the only one it works for then we are no closer to finding out why that is.

And qt builds with no problems with binutils-2.29 so something else must have snuck up between these two versions. Im going to do a diff between them to see what changes has been made.