Hi,
Fedora currently ships Wine 7.3 released February 25th, 2022.
Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64 builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a 'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does not bundle one and does not allow for an alternative compiler.
I will need to drop ARM from Wine in order to continue shipping new updates. I do not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have the time right now to discuss this with upstream.
Thanks, Michael
Hi
What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package.
Thanks Sandro
On 30.03.22 14:33, Michael Cronenworth wrote:
Hi,
Fedora currently ships Wine 7.3 released February 25th, 2022.
Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64 builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a 'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does not bundle one and does not allow for an alternative compiler.
I will need to drop ARM from Wine in order to continue shipping new updates. I do not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have the time right now to discuss this with upstream.
Thanks, Michael _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 3/30/22 7:38 AM, Sandro Mani wrote:
Hi
What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package.
Thanks Sandro
It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain.
[1] https://github.com/mstorsjo/llvm-mingw [2] https://www.mingw-w64.org/downloads/#llvm-mingw
On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth mike@cchtml.com wrote:
On 3/30/22 7:38 AM, Sandro Mani wrote:
Hi
What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package.
Thanks Sandro
It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain.
The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this.
On 30.03.22 15:26, Neal Gompa wrote:
On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth mike@cchtml.com wrote:
On 3/30/22 7:38 AM, Sandro Mani wrote:
Hi
What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package.
Thanks Sandro
It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain.
The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this.
This makes me wonder, is mingw-llvm actually useful? I took interest into it way back when I thought it was necessary to get mingw-rust building, but this turned out not to be the case (resp mingw targets are now built directly in the main rust package). So any point in keeping mingw-llvm around?
On 30.03.22 15:31, Sandro Mani wrote:
On 30.03.22 15:26, Neal Gompa wrote:
On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth mike@cchtml.com wrote:
On 3/30/22 7:38 AM, Sandro Mani wrote:
Hi
What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package.
Thanks Sandro
It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain.
The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this.
This makes me wonder, is mingw-llvm actually useful? I took interest into it way back when I thought it was necessary to get mingw-rust building, but this turned out not to be the case (resp mingw targets are now built directly in the main rust package). So any point in keeping mingw-llvm around?
To add to this: as I understand it's just the llvm backend which could be used on a Windows host, but serve no purpose in cross-compiling from linux to mingw?
On Wed, Mar 30, 2022 at 9:35 AM Sandro Mani manisandro@gmail.com wrote:
On 30.03.22 15:31, Sandro Mani wrote:
On 30.03.22 15:26, Neal Gompa wrote:
On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth mike@cchtml.com wrote:
On 3/30/22 7:38 AM, Sandro Mani wrote:
Hi
What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package.
Thanks Sandro
It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain.
The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this.
This makes me wonder, is mingw-llvm actually useful? I took interest into it way back when I thought it was necessary to get mingw-rust building, but this turned out not to be the case (resp mingw targets are now built directly in the main rust package). So any point in keeping mingw-llvm around?
To add to this: as I understand it's just the llvm backend which could be used on a Windows host, but serve no purpose in cross-compiling from linux to mingw?
The main value for mingw-llvm would be for supporting a mingw-mesa package. The latter needs LLVM infrastructure in the first place to work, and there's a lot of work going on in Mesa around Mesa-on-Windows right now.
On 3/30/22 8:26 AM, Neal Gompa wrote:
The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this.
The configure test in Wine disagrees:
checking for clang... clang checking whether clang works... yes checking whether the cross-compiler supports -target aarch64-windows -fuse-ld=lld -Wl,-subsystem:console... no ...snip... configure: error: PE cross-compilation is required for ARM64, please install clang/llvm-dlltool/lld, or llvm-mingw.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1940475
https://source.winehq.org/git/wine.git/blob/HEAD:/configure.ac
On Wed, Mar 30, 2022 at 9:37 AM Michael Cronenworth mike@cchtml.com wrote:
On 3/30/22 8:26 AM, Neal Gompa wrote:
The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this.
The configure test in Wine disagrees:
checking for clang... clang checking whether clang works... yes checking whether the cross-compiler supports -target aarch64-windows -fuse-ld=lld -Wl,-subsystem:console... no ...snip... configure: error: PE cross-compilation is required for ARM64, please install clang/llvm-dlltool/lld, or llvm-mingw.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1940475
https://source.winehq.org/git/wine.git/blob/HEAD:/configure.ac
That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
-- 真実はいつも一つ!/ Always, there's only one truth!
On 3/30/22 8:42 AM, Neal Gompa wrote:
That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
OK, bug filed.
On 3/30/22 8:51 AM, Michael Cronenworth wrote:
On 3/30/22 8:42 AM, Neal Gompa wrote:
That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
OK, bug filed.
After finding out I'm LLVM-ignorant I added a BR for the LLVM linker to wine to resolve the configure test issue.
The build[1] now fails in a post-compile LLVM rpm script.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -mbranch-protection=standard -fasynchronous-unwind-tables -Wl,-z,relro -Wl,--as-needed -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/wine-7.5/.package_note-wine-7.5-1.fc37.aarch64.ld Checking for LLVM bitcode artifacts Unpacking ar archive /builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a to check for LLVM bitcode components. /tmp/tmp.HfhQjpRaux ~/build/BUILD/wine-7.5 Repacking ./dbghelp.dll into /builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a. /usr/lib/rpm/redhat/brp-llvm-compile-lto-elf: line 34: 569514 Segmentation fault (core dumped) ar r ${archive} ${archived_file}
Who is at fault? Binutils? LLVM?
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84939948
Michael Cronenworth wrote on 2022/03/31 1:25:
On 3/30/22 8:51 AM, Michael Cronenworth wrote:
On 3/30/22 8:42 AM, Neal Gompa wrote:
That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
OK, bug filed.
After finding out I'm LLVM-ignorant I added a BR for the LLVM linker to wine to resolve the configure test issue.
The build[1] now fails in a post-compile LLVM rpm script.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -mbranch-protection=standard -fasynchronous-unwind-tables -Wl,-z,relro -Wl,--as-needed -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/wine-7.5/.package_note-wine-7.5-1.fc37.aarch64.ld Checking for LLVM bitcode artifacts Unpacking ar archive /builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a to check for LLVM bitcode components. /tmp/tmp.HfhQjpRaux ~/build/BUILD/wine-7.5 Repacking ./dbghelp.dll into /builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a. /usr/lib/rpm/redhat/brp-llvm-compile-lto-elf: line 34: 569514 Segmentation fault (core dumped) ar r ${archive} ${archived_file}
Who is at fault? Binutils? LLVM?
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84939948
ar is failing so the fault is in binutils at the first look.
By the way: - First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other static archive) be packed (i.e. are static archives needed in wine binary rpm)? If not, just remove static archives. - If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with -flto, so as a workaround, I think - adding "%global _lto_cflags %nil" - and adding "%global __brp_llvm_compile_lto_elf %nil" should work here.
Regards, Mamoru
On 3/30/22 11:36 AM, Mamoru TASAKA wrote:
ar is failing so the fault is in binutils at the first look.
By the way:
- First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other
static archive) be packed (i.e. are static archives needed in wine binary rpm)? If not, just remove static archives.
Wine offers the ability to compile against it to develop "wine" programs.
- If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with
-flto, so as a workaround, I think - adding "%global _lto_cflags %nil"
This was already added a few years ago.
- and adding "%global __brp_llvm_compile_lto_elf %nil"
should work here.
Thanks. Added.
Now I'm running into another problem[1] with Clang. The MinGW-w64 GCC compiler knows the include search path for MinGW headers. Clang is not finding MinGW headers. Is there a missing environment variable or something that Clang needs to be told where they are?
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84951077
On 3/30/22 17:01, Michael Cronenworth wrote:
On 3/30/22 11:36 AM, Mamoru TASAKA wrote:
ar is failing so the fault is in binutils at the first look.
By the way:
- First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other static archive) be packed
(i.e. are static archives needed in wine binary rpm)? If not, just remove static archives.
Wine offers the ability to compile against it to develop "wine" programs.
- If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with -flto, so
as a workaround, I think - adding "%global _lto_cflags %nil"
This was already added a few years ago.
- and adding "%global __brp_llvm_compile_lto_elf %nil"
should work here.
Thanks. Added.
Now I'm running into another problem[1] with Clang. The MinGW-w64 GCC compiler knows the include search path for MinGW headers. Clang is not finding MinGW headers. Is there a missing environment variable or something that Clang needs to be told where they are?
Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system?
-Tom
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84951077 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 3/30/22 18:33, Tom Stellard wrote:
On 3/30/22 17:01, Michael Cronenworth wrote:
On 3/30/22 11:36 AM, Mamoru TASAKA wrote:
ar is failing so the fault is in binutils at the first look.
By the way:
- First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other static archive) be packed
(i.e. are static archives needed in wine binary rpm)? If not, just remove static archives.
Wine offers the ability to compile against it to develop "wine" programs.
- If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with -flto, so
as a workaround, I think - adding "%global _lto_cflags %nil"
This was already added a few years ago.
- and adding "%global __brp_llvm_compile_lto_elf %nil"
should work here.
Thanks. Added.
Now I'm running into another problem[1] with Clang. The MinGW-w64 GCC compiler knows the include search path for MinGW headers. Clang is not finding MinGW headers. Is there a missing environment variable or something that Clang needs to be told where they are?
Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system?
And actually I see that -I./libs/zlib is present in a recent build with clang: https://kojipkgs.fedoraproject.org//packages/wine/7.3/1.fc37/data/logs/aarch...
But not in the 7.5 build.
-Tom
-Tom
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84951077 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 3/30/22 8:33 PM, Tom Stellard wrote:
Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system?
You may have looked at an older build as that is pointing to the bundled MinGW zlib. My latest build points to the Fedora mingw-zlib package instead.
The zlib.h file lives in the root /$MINGW_ROOT/usr/include path. MinGW gcc knows to look there first without needing an extra "-I" parameter.
$ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list.
Clang apparently has no idea where MinGW files in Fedora live. :(
$ clang -c test.c -target x86_64-windows -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include End of search list.
On 3/30/22 18:59, Michael Cronenworth wrote:
On 3/30/22 8:33 PM, Tom Stellard wrote:
Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system?
You may have looked at an older build as that is pointing to the bundled MinGW zlib. My latest build points to the Fedora mingw-zlib package instead.
The zlib.h file lives in the root /$MINGW_ROOT/usr/include path. MinGW gcc knows to look there first without needing an extra "-I" parameter.
$ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include
Which one of these paths is the one that has the zlib header?
-Tom
End of search list.
Clang apparently has no idea where MinGW files in Fedora live. :(
$ clang -c test.c -target x86_64-windows -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include End of search list.
On 3/30/22 18:59, Michael Cronenworth wrote:
On 3/30/22 8:33 PM, Tom Stellard wrote:
Looking at the builds with gcc, there is an extra option passed to gcc: -I./libs/zlib which is not passed to clang. So maybe this is an issue with the build system?
You may have looked at an older build as that is pointing to the bundled MinGW zlib. My latest build points to the Fedora mingw-zlib package instead.
The zlib.h file lives in the root /$MINGW_ROOT/usr/include path. MinGW gcc knows to look there first without needing an extra "-I" parameter.
$ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list.
Clang apparently has no idea where MinGW files in Fedora live. :(
$ clang -c test.c -target x86_64-windows -v
Try using -target x86_64-w64-mingw32 to match gcc.
-Tom
.. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include End of search list.
On 3/30/22 11:04 PM, Tom Stellard wrote:
$ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed
This path is the Fedora MinGW path:
/usr/x86_64-w64-mingw32/sys-root/mingw/include
End of search list.
Clang apparently has no idea where MinGW files in Fedora live. :(
$ clang -c test.c -target x86_64-windows -v
Try using -target x86_64-w64-mingw32 to match gcc.
Doesn't help.
$ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list.
The "/usr/include" path is a terrible choice. Time to open a bug report?
Michael Cronenworth wrote on 2022/03/31 20:56:
On 3/30/22 11:04 PM, Tom Stellard wrote:
$ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed
This path is the Fedora MinGW path:
/usr/x86_64-w64-mingw32/sys-root/mingw/include
End of search list.
Clang apparently has no idea where MinGW files in Fedora live. :(
$ clang -c test.c -target x86_64-windows -v
Try using -target x86_64-w64-mingw32 to match gcc.
Doesn't help.
$ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list.
The "/usr/include" path is a terrible choice. Time to open a bug report?
Actually it seems --target=foo, not -target foo
$ echo | clang --sysroot=/usr --target=x86_64-w64-mingw32 -v -E - clang version 13.0.1 (Fedora 13.0.1-1.fc36) Target: x86_64-w64-windows-gnu Thread model: posix InstalledDir: /bin (in-process) .... clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target x86_64-redhat-linux-gnu ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/mingw/include" ignoring nonexistent directory "/usr/x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/include End of search list. # 1 "<stdin>" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 361 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "<stdin>" 2
On 3/31/22 7:43 AM, Mamoru TASAKA wrote:
Actually it seems --target=foo, not -target foo
Both argument types work. I had just ignored the "ignoring..." text.
I'll have to use the bundled libs on only ARM arches. We don't have MinGW for ARM in Fedora.
I think this will get us a working build for x86 and ARM arches.
On 3/31/22 9:15 AM, Michael Cronenworth wrote:
I think this will get us a working build for x86 and ARM arches.
Almost. x86 and ARM64 build now. ARM 32-bit has a few issues that neither upstream nor I have time to address. I may end up dropping ARM 32-bit from current Fedora releases seeing it is going away anyway.
Building with gcc: https://koji.fedoraproject.org/koji/taskinfo?taskID=85021941 https://bugs.winehq.org/show_bug.cgi?id=52708
Building with clang: https://koji.fedoraproject.org/koji/getfile?taskID=85059169&volume=DEFAU...
On 3/31/22 04:56, Michael Cronenworth wrote:
On 3/30/22 11:04 PM, Tom Stellard wrote:
$ x86_64-w64-mingw32-gcc -c test.c -v .. snip .. #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed
This path is the Fedora MinGW path:
/usr/x86_64-w64-mingw32/sys-root/mingw/include
End of search list.
Clang apparently has no idea where MinGW files in Fedora live. :(
$ clang -c test.c -target x86_64-windows -v
Try using -target x86_64-w64-mingw32 to match gcc.
Doesn't help.
You need to have the mingw64-gcc package installed. With that installed, I get:
#include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/x86_64-w64-mingw32/sys-root/mingw/include /usr/include
-Tom
$ clang -target x86_64-w64-mingw32 test.c -v .. snip .. #include <...> search starts here: /usr/lib64/clang/13.0.0/include /usr/include End of search list.
The "/usr/include" path is a terrible choice. Time to open a bug report?
On 3/30/22 09:36, Mamoru TASAKA wrote:
Michael Cronenworth wrote on 2022/03/31 1:25:
On 3/30/22 8:51 AM, Michael Cronenworth wrote:
On 3/30/22 8:42 AM, Neal Gompa wrote:
That sounds like a bug in the package, because our LLVM build has all targets enabled on Fedora: https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52
OK, bug filed.
After finding out I'm LLVM-ignorant I added a BR for the LLVM linker to wine to resolve the configure test issue.
The build[1] now fails in a post-compile LLVM rpm script.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -mbranch-protection=standard -fasynchronous-unwind-tables -Wl,-z,relro -Wl,--as-needed -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/wine-7.5/.package_note-wine-7.5-1.fc37.aarch64.ld Checking for LLVM bitcode artifacts Unpacking ar archive /builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a to check for LLVM bitcode components. /tmp/tmp.HfhQjpRaux ~/build/BUILD/wine-7.5 Repacking ./dbghelp.dll into /builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a. /usr/lib/rpm/redhat/brp-llvm-compile-lto-elf: line 34: 569514 Segmentation fault (core dumped) ar r ${archive} ${archived_file}
Who is at fault? Binutils? LLVM?
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84939948
ar is failing so the fault is in binutils at the first look.
It looks like the problem is that the archive is full of COFF files, so that might be what's causing ar to crash. It looks like switching to llvm-ar fixes the crash. I'll talk to the author of brp-llvm-compile-lto-elf and try to found if this is a valid solution.
-Tom
By the way:
- First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any other static archive) be packed
(i.e. are static archives needed in wine binary rpm)? If not, just remove static archives.
- If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang with -flto, so
as a workaround, I think - adding "%global _lto_cflags %nil" - and adding "%global __brp_llvm_compile_lto_elf %nil" should work here.
Regards, Mamoru _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure