Re: Dropping wine from ARM

[Michael Cronenworth]

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

Dropping wine from ARM

[Michael Cronenworth]

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

Dropping wine from ARM

[Mamoru TASAKA]

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

Dropping wine from ARM

[Michael Cronenworth]

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

Dropping wine from ARM

[Tom Stellard]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Dropping wine from ARM

[Tom Stellard]

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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Dropping wine from ARM

[Michael Cronenworth]

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.

Dropping wine from ARM

[Tom Stellard]

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.

Dropping wine from ARM

[Tom Stellard]

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.

Dropping wine from ARM

[Michael Cronenworth]

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?

Dropping wine from ARM

[Mamoru TASAKA]

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

Dropping wine from ARM

[Michael Cronenworth]

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.

Dropping wine from ARM

[Michael Cronenworth]

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...

Dropping wine from ARM

[Tom Stellard]

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?

Dropping wine from ARM

[Tom Stellard]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure