Re: Rebuilding tesseract dependents in F42 for soversion change

Sandro Mani wrote: >This is most likely due to the fact that mingw-crt-12.0.0 for the >mingw32 and mingw64 variants was initially built with the incorrect >default msvcrt. This has since been fixed, but mingw-gcc also needs to >be rebuilt. I'm taking care of this now. Is it also necessary to r

Re: Rebuilding tesseract dependents in F42 for soversion change

On 01.10.24 00:06, Sandro Mani wrote: On 30.09.24 23:35, Neal Gompa wrote: On Wed, Sep 25, 2024 at 2:49 PM Michel Lind wrote: Dear all, This PR: https://src.fedoraproject.org/rpms/tesseract/pull-request/6 was recently merged and built: https://bodhi.fedoraproject.org/updates/FEDORA-2024-41

Re: Rebuilding tesseract dependents in F42 for soversion change

On Tue, Oct 1, 2024 at 4:55 AM Michael J Gruber wrote: > > Am Di., 1. Okt. 2024 um 00:07 Uhr schrieb Sandro Mani : > > > > > > On 30.09.24 23:35, Neal Gompa wrote: > > > On Wed, Sep 25, 2024 at 2:49 PM Michel Lind > > > wrote: > > >> Dear all, > ... > > >> Unfortunately I omitted to mention that

Re: Rebuilding tesseract dependents in F42 for soversion change

On 30.09.24 23:35, Neal Gompa wrote: On Wed, Sep 25, 2024 at 2:49 PM Michel Lind wrote: Dear all, This PR: https://src.fedoraproject.org/rpms/tesseract/pull-request/6 was recently merged and built: https://bodhi.fedoraproject.org/updates/FEDORA-2024-41b92bf172 It backports a PR that's merge

Re: Rebuilding tesseract dependents in F42 for soversion change

On Wed, Sep 25, 2024 at 2:49 PM Michel Lind wrote: > > Dear all, > > This PR: https://src.fedoraproject.org/rpms/tesseract/pull-request/6 > was recently merged and built: > https://bodhi.fedoraproject.org/updates/FEDORA-2024-41b92bf172 > > It backports a PR that's merged upstream to change the Te

Re: Getting fedora boost-mingw to include BoostConfig.cmake

On Mon, Aug 26, 2024 at 11:17 AM Albert Astals Cid wrote: > > El dilluns, 26 d’agost del 2024, a les 3:22:49 (CEST), Neal Gompa va escriure: > > On Sun, Aug 25, 2024 at 3:17 PM Albert Astals Cid wrote: > > > El diumenge, 25 d’agost del 2024, a les 13:23:19 (CEST), Neal Gompa va > > > > > > escriu

Re: Getting fedora boost-mingw to include BoostConfig.cmake

El dilluns, 26 d’agost del 2024, a les 3:22:49 (CEST), Neal Gompa va escriure: > On Sun, Aug 25, 2024 at 3:17 PM Albert Astals Cid wrote: > > El diumenge, 25 d’agost del 2024, a les 13:23:19 (CEST), Neal Gompa va > > > > escriure: > > > On Sun, Aug 25, 2024 at 7:20 AM Neal Gompa wrote: > > > > O

Re: Getting fedora boost-mingw to include BoostConfig.cmake

On Sun, Aug 25, 2024 at 3:17 PM Albert Astals Cid wrote: > > El diumenge, 25 d’agost del 2024, a les 13:23:19 (CEST), Neal Gompa va > escriure: > > On Sun, Aug 25, 2024 at 7:20 AM Neal Gompa wrote: > > > > > > > > > > > On Sun, Aug 11, 2024 at 7:04 PM Albert Astals Cid wrote: > > > > > > > > > >

Re: Getting fedora boost-mingw to include BoostConfig.cmake

El diumenge, 25 d’agost del 2024, a les 13:23:19 (CEST), Neal Gompa va escriure: > On Sun, Aug 25, 2024 at 7:20 AM Neal Gompa wrote: > > > > > > > On Sun, Aug 11, 2024 at 7:04 PM Albert Astals Cid wrote: > > > > > > > > > > > How hard would be for mingw64-boost/mingw32-boost to include > > > B

Re: Getting fedora boost-mingw to include BoostConfig.cmake

El diumenge, 25 d’agost del 2024, a les 13:20:36 (CEST), Neal Gompa va escriure: > On Sun, Aug 11, 2024 at 7:04 PM Albert Astals Cid wrote: > > > > > > > How hard would be for mingw64-boost/mingw32-boost to include > > BoostConfig.cmake? > > > > > > > > boost-devel does but it's on the wrong "sy

Re: Getting fedora boost-mingw to include BoostConfig.cmake

On Sun, Aug 25, 2024 at 7:20 AM Neal Gompa wrote: > > On Sun, Aug 11, 2024 at 7:04 PM Albert Astals Cid wrote: > > > > How hard would be for mingw64-boost/mingw32-boost to include > > BoostConfig.cmake? > > > > boost-devel does but it's on the wrong "sysroot". > > > > It shouldn't be hard, curren

Re: Getting fedora boost-mingw to include BoostConfig.cmake

On Sun, Aug 11, 2024 at 7:04 PM Albert Astals Cid wrote: > > How hard would be for mingw64-boost/mingw32-boost to include > BoostConfig.cmake? > > boost-devel does but it's on the wrong "sysroot". > It shouldn't be hard, currently we're deleting the files instead of keeping them. I'm not sure if

Re: Fedora 38: mingw64-cmake fails when it used to succeed

El dimarts, 12 de setembre de 2023, a les 1:13:20 (CEST), Neal Gompa va escriure: > On Mon, Sep 11, 2023 at 6:47 PM Albert Astals Cid wrote: > > > > > > > Since very recently (it worked 4 days ago), running > > > > > > > > mingw64-cmake -G Ninja .. > > > > > > > > fails with > > > > > > > > /usr

Re: Fedora 38: mingw64-cmake fails when it used to succeed

Hi Neal Gompa, has the issue already been fixed? If not, do you have any idea about when it will be fixed? Best regards. Andrea ___ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-le...@lists.fedoraproject.org

Re: Fedora 38: mingw64-cmake fails when it used to succeed

On Mon, Sep 11, 2023 at 6:47 PM Albert Astals Cid wrote: > > Since very recently (it worked 4 days ago), running > > mingw64-cmake -G Ninja .. > > fails with > > /usr/bin/mingw64-cmake: line 91: fg: no job control > > > Any idea what can be causing it? > > Last time the problem was a missing depen

Re: MinGW ARM support?

On Tue, Sep 13, 2022 at 8:08 AM Greg Hellings wrote: > I thought those didn't support generic applications and could only run > apps from the Microsoft store? > I don't know much about it, but this guy has had some luck building software for himself... https://github.com/drowe67/freedv-gui/issu

Re: Planning to start unifying native and mingw packages

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > Hi > > Following recent discussions and to reduce the maintenance burden, I'm > planning to start merging native and mingw packages. Initially, I'll be > looking at these packages where I maintain both variants: I've done the same wit

Re: Adding mingw64-gtk4 and mingw64-libadwaita

Hmmm... I just wanted to help cross-compile Gnome Text Editor for Windows... but all this seems to be too much of a burden to just start working... And I'm actually a Debian user, so I don't have experience or a working Fedora instance... Is there an alternative way to get packages updated/added wi

Re: Adding mingw64-gtk4 and mingw64-libadwaita

On 6/21/22 2:39 PM, Sim Tov wrote: First question is - how far is what I've found from what is needed? Can it be uploaded as is or not? Hi Sim, No. Fedora compiles its packages from source code. It's a hard requirement. Other distros like Arch or Ubuntu are a little more lenient if you are co

Re: Adding mingw64-gtk4 and mingw64-libadwaita

First question is - how far is what I've found from what is needed? Can it be uploaded as is or not? On Tue, Jun 21, 2022 at 10:37 PM Sandro Mani wrote: > Easiest is if you use an existing rpm spec as a template, i.e. mingw-gtk3 > [1] could serve as a good template. I believe most is self explan

Re: Adding mingw64-gtk4 and mingw64-libadwaita

Easiest is if you use an existing rpm spec as a template, i.e. mingw-gtk3 [1] could serve as a good template. I believe most is self explanatory, but I'm happy to answer any questions. For a packaging tutorial, see [2]. Sandro [1] https://src.fedoraproject.org/rpms/mingw-gtk3/blob/rawhide/f/

Re: Adding mingw64-gtk4 and mingw64-libadwaita

Unfortunately I don't know how to package for Fedora (or any other distro), but I have found this: https://packages.msys2.org/base/mingw-w64-gtk4 https://packages.msys2.org/base/mingw-w64-libadwaita https://packages.msys2.org/base/mingw-w64-gtksourceview5 How different is this from what Fedora ne

Re: Adding mingw64-gtk4 and mingw64-libadwaita

Well the best way to have a package included in the repos is packaging it and submitting it for review. If you do so, I'm happy to review it. Sandro On 19.06.22 22:35, Sim Tov wrote: Anybody here?... On Thu, Jun 16, 2022 at 10:46 AM Sim Tov wrote: Dear mingw maintainers, may I ask

Re: Adding mingw64-gtk4 and mingw64-libadwaita

Anybody here?... On Thu, Jun 16, 2022 at 10:46 AM Sim Tov wrote: > Dear mingw maintainers, > > may I ask you, please, to add mingw64-gtk4 and mingw64-libadwaita to > Fedora, so people can start cross-compile modern GTK4 applications for > Windows. > > BTW, is it possible to cross-compile mingw64

Re: mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide

On Thu, 24 Mar 2022 at 08:49, Sandro Mani wrote: > > > On 14.03.22 23:50, Sandro Mani wrote: > > Hi > > > > As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38 > > towards the end of the week. I've completed test-builds here [2]. > > Looks like there is an ABI incompatibility (std::

Re: Standard DLL provides

The reason for having the standard provides at all, or the reason they are in mingw-filesystem? The reason for having them at all is just for uniformity. You can "BuildRequires: mingw(wsock32.dll)" and not care whether that comes from Windows/Wine or from Fedora. The reason they are in mingw

Re: Standard DLL provides

On Tue, May 03, 2022 at 04:46:34PM +0200, Sandro Mani wrote: > > >>Any comments/objections? > >> > >> > >>That seems to make sense to me, is there a reason why it wasn't before? > >> > As far as I see mingw-filesystem provided the standard DLLs since > the beginning of the package, perhaps @rjones

Re: Standard DLL provides

Any comments/objections? That seems to make sense to me, is there a reason why it wasn't before? As far as I see mingw-filesystem provided the standard DLLs since the beginning of the package, perhaps @rjones can recall if there was a reason? ___

Re: Standard DLL provides

On Tue, May 3, 2022 at 9:59 AM Sandro Mani wrote: > > Hi > > Currently mingw-filesystem contains > > # (rpm -ql mingw32-crt | grep '\.a$' | while read f ; do > i686-w64-mingw32-dlltool -I $f 2>/dev/null ; done) | sort | uniq | tr > A-Z a-z > standard-dlls-mingw32 > Source20: standard-dlls-

Re: HEADS UP: mingw-w64-10.0.0 coming to rawhide

On 4/27/22 6:47 AM, Sandro Mani wrote: I'll be updating to mingw-w64-10.0.0 in rawhide over the next day or two. I did an initial test-run here [1] and everything worked smoothly. The real test will be if wine-gecko still builds. :) ___ mingw mailing

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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 Fed

Re: Dropping wine from ARM

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 F

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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 t

Re: Dropping wine from ARM

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 t

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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 archive

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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 archiv

Re: Dropping wine from ARM

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#_5

Re: Dropping wine from ARM

On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth 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

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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.

Re: Dropping wine from ARM

On Wed, Mar 30, 2022 at 10:44 AM NightStrike wrote: > > > > On Wed, Mar 30, 2022, 08:34 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.

Re: Dropping wine from ARM

On Wed, Mar 30, 2022, 08:34 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 > no

Re: Dropping wine from ARM

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

Re: Is mingw-llvm useful? (was Re: Dropping wine from ARM)

On Wed, Mar 30, 2022 at 9:35 AM Sandro Mani 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 > >> wrote: > >>> On 3/30/22 7:38 AM, Sandro Mani wrote: > Hi > > What does llvm-ming

Re: 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 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

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

Re: Dropping wine from ARM

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

Re: Dropping wine from ARM

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

Re: mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide

On 24.03.22 09:49, Sandro Mani wrote: On 14.03.22 23:50, Sandro Mani wrote: Hi As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38 towards the end of the week. I've completed test-builds here [2]. Looks like there is an ABI incompatibility (std::__once_functor went away),

Re: mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide

On 14.03.22 23:50, Sandro Mani wrote: Hi As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38 towards the end of the week. I've completed test-builds here [2]. Looks like there is an ABI incompatibility (std::__once_functor went away), I'll need to rebuild all dependent mingw

Re: Linking fails with 32-bit vulkan libs

On 3/14/22 4:55 PM, Sandro Mani wrote: Odd, working fine here, though had to add -lpathcch: i686-w64-mingw32-gcc -o test test.c -lvulkan-1 -lpathcch Adding that didn't help. It also fails on Koji builders when I tried a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=845

Re: Linking fails with 32-bit vulkan libs

On 14.03.22 22:11, Michael Cronenworth wrote: Hi, In trying to prepare the vkd3d library for cross-compiling I ran into a gcc/linker error. Reproducer: char main(void) {     char vkGetInstanceProcAddr ();     return vkGetInstanceProcAddr (); } $ i686-w64-mingw32-gcc -o test test.c -lvulkan-

Re: Planning to start unifying native and mingw packages

On 14.03.22 14:13, Daniel P. Berrangé wrote: On Mon, Mar 14, 2022 at 01:06:34PM +, Daniel P. Berrangé wrote: On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw pa

Re: Planning to start unifying native and mingw packages

On 14.03.22 14:02, Michael Cronenworth wrote: On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? As far as I ca

Re: Planning to start unifying native and mingw packages

On Mon, Mar 14, 2022 at 01:06:34PM +, Daniel P. Berrangé wrote: > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > Hi > > > > Following recent discussions and to reduce the maintenance burden, I'm > > planning to start merging native and mingw packages. Initially, I'll be > > l

Re: Planning to start unifying native and mingw packages

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > Hi > > Following recent discussions and to reduce the maintenance burden, I'm > planning to start merging native and mingw packages. Initially, I'll be > looking at these packages where I maintain both variants: Thanks for driving thi

Re: Planning to start unifying native and mingw packages

On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? Upstream wine has begun to depend on .dll files. Wine 7.3 bundl

Re: error: reference to 'byte' is ambiguous

On Sun, 13 Feb 2022, at 01:16, Richard Shaw wrote: > Yeah, I had a few instances of that, but in this case it's not being used in > logger.cxx. It appears the MinGW headers are conflicting with themselves and > they don't seem to want to admit the problem or fix it. > > https://gcc.gnu.org/bugzi

Re: mingw-openssl 3.0 update

If there are no objections I'd file a self-contained change to get this into F37. I'd also file a self-contained change for the toolchain updae (GCC12 and possibly binutils 2.38). Sounds good, thanks Submitted: https://fedoraproject.org/wiki/Changes/F37MingwOpenSSL3

Re: mingw-openssl 3.0 update

Hi On Mon, Jan 31, 2022 at 2:05 AM Sandro Mani wrote: > > Hi > > I've tested the mingw-openssl-3.0 update in this COPR repo [1]. All > builds succeeded right away except for mingw-spice-gtk which I needed to > update from version 0.37 to 0.39 (and as a dependency > mingw-spice-protocol from versi

Re: ucrt plans ?

On 1/14/22 8:03 AM, Sandro Mani wrote: If memory serves me right, there were still some use-cases for mingw32, perhaps mingw-gecko/wine? Michael can you add more maybe? Sorry for the late reply. Yes, mingw32 would still be needed to build wine-gecko. __

Re: ucrt plans ?

On 28.01.22 22:35, Marc-André Lureau wrote: Yes, it's mingw with a different target runtime. Until ucrt, the target was only x86/x86-64 msvcrt, so mingw32/mingw64 prefix was used. I propose to add the ucrt64 prefix for the MinGW UCRT64 x86-64 Fedora packages. To be pedantic, we should use someth

Re: ucrt plans ?

. To be pedantic, we should use something like "mingw-w64-ucrt-x86_64" as package prefix I guess. ucrt64 is a reasonable short form. That's also what msys2 picked for their environment (MSYSTEM) and prefix (/ucrt64) So it's not about renaming mingw64-zlib to mingw64-msvc-zlib, and

Re: ucrt plans ?

g than mingw, but it's just mingw with the different runtime right? So to be precise, the one package should be called say mingw64-msvc-zlib while the other mingw64-ucrt-zlib? - ask FESCO to rename without re-rereview all mingw32/64-* packages to win32/64-* (or whatever generic windows prefix),

Re: ucrt plans ?

b & mingw64-zlib today. We would have to add a third ucrt64-zlib. It's tedious, but we don't have to do it all in one go, we can add it over time. And with the simple template system I propose (until RPM provides something) it is easier to adapt, it avoids having to repeat things.

Re: ucrt plans ?

- ask FESCO to rename without re-rereview all mingw32/64-* packages to win32/64-* (or whatever generic windows prefix), leaving the runtime out of the package name - when the time comes, change the runtime and just recompile the entire mingw/win package set So not even ever offering mingw and u

Re: ucrt plans ?

Hi Sandro On Fri, Jan 28, 2022 at 11:02 PM Sandro Mani wrote: > > Thanks Marc > > Just for curiosity, as you see it, does it make sense to keep both mingw > and ucrt moving forward? > Interesting question, it really depends on our users I imagine. Since Windows recommends ucrt since Windows 10

Re: Review requests: mingw-python-tomli, mingw-qt6-qt5compat, mingw-qt6-qtwebchannel

Forwarding to this list... I'd greatly apprechiate in particular the review of mingw-python-tomli. Thanks Sandro On 24.01.22 08:59, Sandro Mani wrote: Hi I have the following packages up for review: - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2044188 - mingw-python-tomli - https:

Re: ucrt plans ?

Thanks Marc Just for curiosity, as you see it, does it make sense to keep both mingw and ucrt moving forward? Sandro On 28.01.22 16:00, Marc-André Lureau wrote: Hi On Sat, Jan 15, 2022 at 4:36 PM Marc-André Lureau wrote: Any comments? How to proceed next? I wrote a Fedora change proposal

Re: ucrt plans ?

Hi On Sat, Jan 15, 2022 at 4:36 PM Marc-André Lureau wrote: > > Any comments? How to proceed next? I wrote a Fedora change proposal: https://fedoraproject.org/wiki/Changes/F37MingwUCRT Regarding update of the mingw-* libraries packages (to add or remove targets in the future), I have looked at

Re: ucrt plans ?

Hi Sandro & all On Fri, Jan 14, 2022 at 6:03 PM Sandro Mani wrote: > > Hi Marc > > On my part, feel free to give it a shot. To be honest personally I don't > really know enough about UCRT to judge the consequences. > I managed to bootstrap a ucrt toolchain on fedora: $ x86_64-w64-mingw32ucrt-gc

Re: ucrt plans ?

Hi Marc On my part, feel free to give it a shot. To be honest personally I don't really know enough about UCRT to judge the consequences. Regarding mingw32, I think the discussion came up some time ago when I proposed changing the mingw32 exception model to be able to build rust. If memory s

Re: Adding mingw package for libuuid-devel (with pkg-config file uuid.pc)

Hi 1. Does the existence of these files imply that libuuid-devel was actually added to MinGW, just not as a separate package? /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libuuid.a This one is in mingw-crt /usr/x86_64-w64-mingw32/sys-root/mingw/include/uuids.h This one is in mingw-headers

Re: Adding mingw package for libuuid-devel (with pkg-config file uuid.pc)

PS: I've opened Fedora's native /usr/include/linux/uuid.h from libuuid-devel and it looks quite Linux specific... Here is what I've found regarding porting uuid to windows: https://trac.xapian.org/ticket/303 see this (and other patches there): https://trac.xapian.org/attachment/ticket/303/window

Re: Merging mingw specs into native spec

On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote: > V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a): > > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote: > > > +%if %{_with_mingw} > > > + > > > +%package -n mingw32-libvirt-glib > > > +Summary: Ming

Re: Merging mingw specs into native spec

On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote: > V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a): > > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote: > > > +%if %{_with_mingw} > > > + > > > +%package -n mingw32-libvirt-glib > > > +Summary: Ming

Re: Merging mingw specs into native spec

On Tue, Mar 02, 2021 at 11:21:16AM -0500, Neal Gompa wrote: > On Tue, Mar 2, 2021 at 11:13 AM Greg Hellings wrote: > > > > > > > > On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote: > >> > >> [Adding the devel list, since this change would obviously affect > >> several "base" packages.] > >

Re: Merging mingw specs into native spec

On Tue, Mar 02, 2021 at 10:13:38AM -0600, Greg Hellings wrote: > On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote: > > > [Adding the devel list, since this change would obviously affect > > several "base" packages.] > > > > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote

Re: Merging mingw specs into native spec

On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote: > [Adding the devel list, since this change would obviously affect > several "base" packages.] > > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote: > > Way back when we first started the mingw project in Fedora we took th

Re: Merging mingw specs into native spec

> Way back when we first started the mingw project in Fedora we took the > decision to maintain the mingw builds as separate source RPMs in Fedora. > The rationale was that mingw support was a new concept to Fedora with > many unknowns. We often had custom mingw only patches, and there was a > dece

Re: Fwd: Macros for trivial mingw-python-* packages

ssage Subject: Re: Macros for trivial mingw-python-* packages Date: Fri, 6 Nov 2020 09:12:18 +0100 From: Sandro Mani To: Miro Hrončok Hey Sandro. Before we proceed, would it make sense to introduce some macros for this, similar to %py3_build and %py3_install? E.g. you should be ab

Re: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

On 8/4/20 3:17 AM, Sandro Mani wrote: * mingw-wine-gecko: internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359 => needs an upstream bug report with preprocessed source It's been filed. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 _

Re: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

On 7/19/20 4:35 PM, Sandro Mani wrote: So now the toolchain update is pushed, I'll keep an eye on failures during the upcoming mass rebuild. I see the following build failures: Related to -fstack-protector/-lssp: * mingw-openssl: undefined reference to ***_chk * mingw-boost: undefined refer

Re: Retiring my gstreamer 0.10 packages

On 7/29/20 1:13 PM, Michael Cronenworth wrote: The following packages are failing the F33 rebuild. I don't wish to fix them. * mingw-gstreamer-plugins-good * mingw-gstreamer-plugins-bad-free If anyone wants to take them let me know otherwise they will be retired in a few days. These are now

Re: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

On 7/19/20 4:35 PM, Sandro Mani wrote: So now the toolchain update is pushed, I'll keep an eye on failures during the upcoming mass rebuild. An internal compiler error occurred during the mingw-wine-gecko rebuild. https://koji.fedoraproject.org/koji/taskinfo?taskID=48000438 I rebuilt using g

Re: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

I've worked around this for now by symlinking bin/libssp-0.dll over lib/libssp.dll.a, not having any other ideas. I've also added -fstack-protector to the mingwXX_ldflags, as the mingwXX_cflags contain -D_FORTIFY_SOURCES=2. So now the toolchain update is pushed, I'll keep an eye on failures d

Re: mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'

On Thu, 2020-07-09 at 00:07 +0200, Sandro Mani wrote: > I'm working on updating the mingw toolchain [1], and am hitting the > situation [2] where I build with -fstack-protector in the ldflags, can > confirm that -lssp and -lssp_nonshared are automatically added to the > ldflags (seen via gcc -v

Re: mingw_cflags vs optflags

Hi Revisiting this, I've hit [1] during the ongoing toolchain upgrade, so as I read it since we have -Wp,-D_FORTIFY_SOURCE=2 in the cflags we'll also need -fstack-protector in the ldflags, and gcc should take care of adding -lssp -lssp_nonshared automatically (trying this out here [2]). An

Re: Differences in 32bit and 64bit builds

On 6/11/20 17:49, Richard Shaw wrote: On Thu, Jun 11, 2020 at 10:43 AM Jan Niklas Hasse > wrote: __ On Wed, 10 Jun 2020, at 23:09, Richard Shaw wrote: So why does this only show up in MinGW? If a 64bit pointer can't find it a 32bit int, shouldn't I als

Re: Differences in 32bit and 64bit builds

On Wed, 10 Jun 2020, at 23:09, Richard Shaw wrote: > So why does this only show up in MinGW? If a 64bit pointer can't find it a > 32bit int, shouldn't I also get an error when building for 64bit Fedora? Because ShellExecute is a Windows function, thus that part of the code won't be compiled when

Re: Differences in 32bit and 64bit builds

On Wed, 2020-06-10 at 10:26 -0500, Richard Shaw wrote: > I'm working on the ability to produce Windows builds of fldigi using > the Fedora MinGW stack. > > Currently the 32bit builds compile with little to no warnings and > appear to function properly, however, on 64bit builds there is a ton > mor

Re: Adding %mingw_make_build and %mingw_make_install

> On 23 May 2020, at 14:10, Sandro Mani wrote: > > > > On 22.05.20 21:35, Greg Hellings wrote: >> Please do! >> >> --Greg >> >> On Fri, May 22, 2020 at 1:50 PM Sandro Mani wrote: >> Hi >> >> I'm thinking of adding %mingw_make_build and %mingw_make_install as >> counterparts to %make_build

Re: Adding %mingw_make_build and %mingw_make_install

On 22.05.20 21:35, Greg Hellings wrote: Please do! --Greg On Fri, May 22, 2020 at 1:50 PM Sandro Mani > wrote: Hi I'm thinking of adding %mingw_make_build and %mingw_make_install as counterparts to %make_build and %make install, see [1]. Comments

Re: mingw_cflags vs optflags

On Fri, 2020-05-22 at 22:25 +0200, Sandro Mani wrote: > While looking through the mingw rpm macros, I noticed that we currently have > > mingw{32,64}_cflags = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions --param=ssp-buffer-size=4 > > whereas for native packages we have > > optflags

Re: Adding %mingw_make_build and %mingw_make_install

Please do! --Greg On Fri, May 22, 2020 at 1:50 PM Sandro Mani wrote: > Hi > > I'm thinking of adding %mingw_make_build and %mingw_make_install as > counterparts to %make_build and %make install, see [1]. > Comments/objections? > > Sandro > > [1] https://src.fedoraproject.org/rpms/mingw-filesyst

  1   2   3   4   5   6   7   8   >