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