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