Rewinding the discussion on MinGW+Wine
by Paolo Bonzini
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
14 years, 9 months
[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla
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.
14 years, 9 months
[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla
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.
14 years, 9 months
[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla
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.
14 years, 9 months
[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla
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.
14 years, 9 months
[Bug 509940] Cmake can't build sdl program with mingw32
by Red Hat Bugzilla
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.
14 years, 9 months
[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla
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.
14 years, 9 months
[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla
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.
14 years, 9 months