7:33 a.m.
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
7:38 a.m.
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
8:25 a.m.
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
8:26 a.m.
On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth <mike(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
8:31 a.m.
New subject: Is mingw-llvm useful? (was Re: Dropping wine from ARM)
On 30.03.22 15:26, Neal Gompa wrote:
On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth
<mike(a)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?
8:35 a.m.
New subject: Is mingw-llvm useful? (was Re: Dropping wine from ARM)
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(a)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?
8:37 a.m.
New subject: Is mingw-llvm useful? (was Re: Dropping wine from ARM)
On Wed, Mar 30, 2022 at 9:35 AM Sandro Mani <manisandro(a)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(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
8:37 a.m.
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
8:42 a.m.
On Wed, Mar 30, 2022 at 9:37 AM Michael Cronenworth <mike(a)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!
8:51 a.m.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2070151
11:25 a.m.
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2070151
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
11:36 a.m.
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.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2070151
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
7:01 p.m.
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
8:33 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
8:47 p.m.
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/aa...
But not in the 7.5 build.
-Tom
-Tom
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84951077
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
8:59 p.m.
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.
9:02 p.m.
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.
11:04 p.m.
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.
6:56 a.m.
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?
7:43 a.m.
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
9:15 a.m.
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.
9:30 a.m.
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=DE...
11:32 a.m.
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?
8:29 p.m.
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.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2070151
>
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
765
days inactive
768
days old
23 comments
5 participants
participants (5)
-
Mamoru TASAKA -
Michael Cronenworth -
Neal Gompa -
Sandro Mani -
Tom Stellard