mingw July 2009

mingw@lists.fedoraproject.org

15 participants
97 discussions

Rewinding the discussion on MinGW+Wine
by Paolo Bonzini 27 Jul '09

27 Jul '09

All, this email will summarize my recent flurry of bugs, all coming from the attempt to use the cross-compilation and Wine environments together. The reason for this attempt is that I had to *develop* a port, not just to compile it; therefore I had to test it. The fact that my particular package runs itself at make time, so that (at the moment) it needs Wine to compile, is secondary and would confuse the matter. Secondarily, I wanted to make sure that the compilation works not just for me, but also for people running native Windows, hence my installing MSYS under Wine. While not something that I want to do day-to-day, this is important to support MinGW as well as possible, and I wanted to reuse as much of the Fedora cross-compilation install in order to achieve it. Now, I can say my attempt succeeded but only after working around what seemed to me like bugs. Maybe they are, maybe not; so, let's look at them. 513819: this is just the fact mingw's sys-root is *not* exported to Wine. Nothing else, nothing more. It is totally unrelated from the fact that Autoconf thinks it's not cross-compiling anymore. The question is one, we can frame it in two ways: 1) Do we want this? If not, why? 2) Or as a meta-question: What relationship do we want between Wine and the cross-compilation environment? Isolation or cooperation? (Of course having one require the other is a no-no). A side note: one reason to do this, is to have a place to install updates that would propagate automatically to all users' ~/.wine directories. Again, maybe it's a good reason---maybe not. 513824: definitely a hack, but one that we cannot skip if we want the cross-compilation environment to cooperate Wine. It is extremely stupid to use touch instead of open, but glib does it; bummer. Fixing it upstream will require years to propagate to packages. There are more ways to fix this: 1) provide a minimal touch binary in mingw32-glib. The problem is where to place it so that the Wine filesystem sees it. Placing it in /mingw requires forward thinking (because MSYS 1.0.11 can be installed in /mingw and we want to avoid conflict with MSYS's touch.exe) and it would require agreeing on fixing 513819 would be a good start, even though probably it would not work for people that already have a .wine in their home directories. 2) provide a minimal touch binary with Wine. Kind of sucks, again because of people that already have a .wine in their home directories. It also feels terribly out-of-place. 3) package MSYS and make mingw32-glib depend on it. Overkill for people that do not require wine, but maybe the simplest alternative. 4) find a way to define a config.site file (coordinating with the Fedora setup.rpm maintainers) and disable glibtest for MinGW (but also gtktest, etc.). 513825: I think there is consensus that mingw32-pkg-config should be renamed or at least both names should be provided. The other discussions in the bug are about: 1) mingw32-configure and mingw32-make. This can be ignored as long as we agree that "./configure --host=i686-pc-mingw32 && make" should be a valid way to compile mingw32 packages. 2) Problems in the default RPM macros. This can be skipped, except maybe for making -mms-bitfields the default in the compiler. I can bring this upstream. 513825, reprise. There is another aspect of this bug. When Wine is installed, Autoconf executes run-time testcases. This can be seen as a bug, but it is also a feature---and for three reasons. First, in most cases run-time testcases choose a conservative answer when cross-compiling, so that allowing them would make for slimmer or more efficient binaries. Second, some run-time testcases may detect problems in usage or in the existing installation, as is the case with the glib testcase in bug 513825. Third, they remove the need (for the casual user of the cross-compiler, not for the packager) to define a config.cache or config.site file in case the package does not support cross-compilation. The question is obvious: So, is it a bug or a feature? 513826: This is currently just an aesthetic problem, but if we decide to export the sys-root to Wine it becomes worse, because then it would be very very hard to install pkgconfig under Wine. I think that there is no reason to make it so hard. Installing MinGW and MSYS themselves under Wine is extremely easy, it works, and there are use cases for doing it, even though it may seem a weird thing to do. If you want to free developers from using Windows, allowing them to use MSYS is a good thing. That said, this bug requires touching all packages and the packaging guidelines. So, it's something that maybe you would like to have, but it's nevertheless likely to be postponed indefinitely. I would understand that. That's it; thanks for reading all this. Paolo

2 1

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 27 Jul '09

27 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #12 from Richard W.M. Jones <rjones(a)redhat.com> 2009-07-27 04:48:32 EDT --- > 1. install mingw-gcc, mingw-gtk2, and non-mingw glib Hmmm - I don't really care what happens when you install a "non-mingw glib". Use our mingw32-glib. > 1) when given --host, Autoconf tries to run a program to determine if you're > cross compiling. If you have Wine installed the Windows executable are > registered with the kernel binfmt_misc module and then you're not > cross-compiling, or at least Autoconf doesn't think you are. This is a real bug (with autotools). I've raised it with Jim Meyering some time ago. No one has found a good way to fix it, but the workaround is to kill Wine's binfmt_misc handler before running the configure script. > [Smalltalk] Please take a look at how we built mingw32-ocaml. {BTW this should be discussed on the mailing list, because discussing it in Bugzilla entries is hard to follow, and while there may be bugs, I'm not convinced there is a 1-1 correspondence between bugs and the four Bugzillas that happen to be opened now.} -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 27 Jul '09

27 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #11 from Paolo Bonzini <pbonzini(a)redhat.com> 2009-07-27 02:58:45 EDT --- Wait wait, we're talking about two different things. I'm not talking about packaging GNU Smalltalk for Fedora. I'm talking about developing Windows programs on Linux using MinGW and Wine, and the problems I had with it *while trying it out on GNU Smalltalk*. (Don't be confused by my @redhat.com; this is not something I'm doing for my job). > I'm guessing this is a bootstrapping problem - ie. the Smalltalk > compiler/runtime is written in Smalltalk, so must be compiled > using Smalltalk. Yes, it runs the VM executable to compile the runtime. It would be possible to do as said in comment #9 (the output file is the same for i686-linux and i686-mingw32,some files are even the same for all architectures), or just to BuildRequire the native package and copy bits from its /usr/share and /var/lib into the target package. But let's not get distracted from the main issue, which is about interactions between wine (which makes the i686-pc-mingw32 not really a cross compiler anymore) and the cross compilation environment. Wine and a cross-compiler will not really be installed together by Koji, but they definitely will be together on a Fedora user's machine (such as me). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 509940] Cmake can't build sdl program with mingw32
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=509940 --- Comment #6 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> 2009-07-26 17:59:36 EDT --- mingw32-cmake is only available in mingw32-filesystem-51-1.fc12 (or higher) so only rawhide -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #10 from Thomas Sailer <t.sailer(a)alumni.ethz.ch> 2009-07-26 16:50:26 EDT --- > Actually there's an even more fundamental problem - Wine > requires an X server and a $HOME directory to function, and > for those reasons I never managed to get it to run under > Koji (even using Xvfb). You don't necessarily need an X server, I successfully use wine with a windows console application without X (just unset DISPLAY before calling wine). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #9 from Richard W.M. Jones <rjones(a)redhat.com> 2009-07-26 16:40:48 EDT --- (In reply to comment #8) > This won't currently work anyway. MinGW packages are noarch. koji builders will > select any free builder, and often use ppc or ppc64 builders. On ppc machines, > wine will not work. So if you want this to work, you need to file an RFE for > koji. Actually there's an even more fundamental problem - Wine requires an X server and a $HOME directory to function, and for those reasons I never managed to get it to run under Koji (even using Xvfb). (In reply to comment #6) > 2) The reason GNU Smalltalk's build needs Wine is not needing runtime tests, > but rather that it needs to run itself to complete the build. This is not > related to this bug. I'm guessing this is a bootstrapping problem - ie. the Smalltalk compiler/runtime is written in Smalltalk, so must be compiled using Smalltalk. We have other packages like this (certainly mingw32-ocaml, possibly our Tcl package too). The standard solution is to BuildRequire the *native* package, and use that to run the bits that need to be run during the build. With OCaml this was especially complex, but that's what we did. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 509940] Cmake can't build sdl program with mingw32
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=509940 --- Comment #5 from Paolo Bonzini <pbonzini(a)redhat.com> 2009-07-26 16:13:21 EDT --- Maybe using mingw32-cmake? Erik mentioned it but I didn't find it in my installation. As I wrote extensively in 513925, the need for special commands instead of "./configure --host=... && make" (or the cmake equivalent) is always the sign of a bug (either in the program's build system, or in Fedora). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 Thomas Sailer <t.sailer(a)alumni.ethz.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |t.sailer(a)alumni.ethz.ch --- Comment #8 from Thomas Sailer <t.sailer(a)alumni.ethz.ch> 2009-07-26 16:12:54 EDT --- (In reply to comment #6) > 2) The reason GNU Smalltalk's build needs Wine is not needing runtime tests, > but rather that it needs to run itself to complete the build. This is not > related to this bug. This won't currently work anyway. MinGW packages are noarch. koji builders will select any free builder, and often use ppc or ppc64 builders. On ppc machines, wine will not work. So if you want this to work, you need to file an RFE for koji. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #6 from Paolo Bonzini <pbonzini(a)redhat.com> 2009-07-26 15:03:22 EDT --- There are three problems: 1) when given --host, Autoconf tries to run a program to determine if you're cross compiling. If you have Wine installed the Windows executable are registered with the kernel binfmt_misc module and then you're not cross-compiling, or at least Autoconf doesn't think you are. So glib will run the runtime tests that detect mismatches between the versions in the include files and the actual library versions. While I agree that necessary runtime tests are evil, they can be useful when they are supported because they are more precise that compile-only tests. Indeed in my case it detected that I was using the wrong pkg-config (bug 513825). That's why it is ok to report this as a wine bug, also. The bug doesn't happen if Wine is not installed. 2) The reason GNU Smalltalk's build needs Wine is not needing runtime tests, but rather that it needs to run itself to complete the build. This is not related to this bug. > Wine's behaviour when executing programs which depend on other (cross- > compiled) libraries is the same as would happen on real Windows environments. > That is: only the default paths and the current path are searched for > libraries. I know, but this bug applies to uninstalled binaries. It is currently impossible to run a quick-and-dirty glib/gtk program in Wine except by manually adding c:\mingw\bin to the path. (BTW, I stand corrected; adding c:\mingw\lib is not required). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw July 2009