dev-util/mingw64-toolchain-11.0.0_p2 compilation errpr Reproducible: Always
Created attachment 880182 [details] build.log
Created attachment 880183 [details] emerge --info
configure: error: C compiler cannot create executables See `config.log' for more details Please include: /var/tmp/portage/dev-util/mingw64-toolchain-11.0.0_p2/work/mingw64_libraries32-build/mingw-w64-libraries/libmangle/config.log (hopefully the right one+path, lot of config.log in this) I'd suspect it's related to your clang setup, albeit last time I tried clang it was fine and should work in theory (i.e. it "should" have stripped -fuse-ld=lld to use mingw's ld.bfd, -flto=thin should be gone too). Maybe something different with your setup from mine that cause issues though, hopefully config.log will make that obvious.
Created attachment 880198 [details] config.log
Created attachment 880199 [details] package.env
Created attachment 880200 [details] compiler-gcc-ld
(In reply to Alexander Polozov from comment #4) > Created attachment 880198 [details] > config.log I don't think that's the right one, looks like took mingw64_libraries32-build/config.log rather than the one I asked for at mingw64_libraries-build/mingw-w64-libraries/libmangle/config.log There will be a "checking whether the C compiler works" line in it along with why it failed.
(In reply to Ionen Wolkens from comment #7) > mingw64_libraries-build/mingw-w64-libraries/libmangle/config.log err missed the 32, meant mingw64_libraries32-build/mingw-w64-libraries/libmangle/config.log well the former path in comment #3 should be right /var/tmp/portage/dev-util/mingw64-toolchain-11.0.0_p2/work/mingw64_libraries32-build/mingw-w64-libraries/libmangle/config.log
Created attachment 880235 [details] libmangle\config.log
lib32/libmsvcrt.a: error adding symbols: file format not recognized collect2: error: ld returned 1 exit status It doesn't show anywhere (emerge --info doesn't show this variable), but only way I could reproduce is by setting DLLTOOL="llvm-dlltool" which ends up creating an unusable library. So I assume you have it set. First time I've seen this set (llvm profile doesn't set it either), and hadn't considered it in the list of variables to unset for cross which I'll fix.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db21b95652247c4181a0b92e47421f885d942c66 commit db21b95652247c4181a0b92e47421f885d942c66 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-12-22 17:08:44 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-12-22 17:37:24 +0000 dev-util/mingw64-toolchain: unset DLLTOOL for cross Rarely set but, if it is, can result in using llvm-dlltool when it should be using mingw's, and ultimately fails. Closes: https://bugs.gentoo.org/920483 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-util/mingw64-toolchain/mingw64-toolchain-11.0.0_p2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5e53d7ae39660784580f720eae5e21811e671d35 commit 5e53d7ae39660784580f720eae5e21811e671d35 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-12-22 17:11:24 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-12-22 17:37:24 +0000 dev-util/mingw64-runtime: unset DLLTOOL for cross Likely less of an issue on this package than mingw64-toolchain, but doesn't hurt to unset either way. Bug: https://bugs.gentoo.org/920483 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-util/mingw64-runtime/mingw64-runtime-11.0.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
