The idea that Wine and cross-compilation are either isolated or "cooperate" is a false dichotomy. The only reason this problem occurs for you is that you're using some other glib which isn't mingw32-glib. Use mingw32-glib and our cross-compilation environment, or explain why we should support some other binary glib that we have no control over.
But I'm not! I'm just using *your* glib and I happen to have the Linux one installed! When I said "non-mingw glib" I was referring to the normal Linux glib.
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.
Why can't this "other" glib (whatever it is) use /usr/bin/touch?
It is not "another" glib, it is glib-2.0.m4 that is the same for every package and every architecture. It runs touch from within a runtime test, so it tries to use a non-existing Windows touch.
- 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.
We used to require -mms-bitfields to make interoperable C structures. _If_ that's now the default, we can drop it.
It's not the default, we have to bring the case upstream then.
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.
Nevertheless, we can't use wine at compile time, no matter how much better it might theoretically make things. We can't use it because (a) it doesn't work in Koji, and (b) cross-compilation should not need to run generated binaries at build time [autoconf section 6.6 Checking Runtime Behavior].
First of all, let's put aside Make-time generated binaries. They are just complicating the discussion, the problem occurs with any program that uses glib (*).
I understand perfectly why you do not want to use Wine at compile time. Someone in the bugzilla audit trails said it does not require X . And that's not the reason indeed, just like the reason is not that it requires a $HOME (it does not---just use WINEPREFIX). The reason is that you want the packages to build on any architecture where the cross-compiler builds, which makes lots of sense.
And I agree that run-time tests should not be needed.
My question is this one: where does the scope of Fedora MinGW end? Do you want to discourage/allow/encourage *users* from coupling it with Wine so that it is an *emulation* environment and the cross-compiler becomes sort-of native? As I said, it wouldn't be unheard of; I know of companies that do the same using Qemu's user-space Linux emulation.
And if so, do you agree that allowing run-time configure tests can be advantageous because of possibly increased precision and easier setup?
Paolo
(*) Try it yourself. Install wine, glib2-devel, mingw-glib2, and run this script:
cat > configure.ac << \EOF AC_INIT AM_PATH_GLIB_2_0(2.0.0) AC_OUTPUT(Makefile) EOF
cat > Makefile.in << \EOF CC = @CC@ CFLAGS = -O2 -g EXEEXT = @EXEEXT@ override CFLAGS += @GLIB_CFLAGS@ override LIBS += @GLIB_LIBS@
hello$(EXEEXT): hello.o ; $(CC) -o $@ $^ $(LIBS) hello.o: hello.c Makefile: Makefile.in config.status; ./config.status config.status: configure; ./config.status --recheck configure: configure.ac; autoconf clean: ; rm config.status Makefile hello.o hello$(EXEEXT) EOF
cat > hello.c << \EOF #include <glib.h> #include <stdio.h>
int main() { printf ("%s\n", g_strdup ("Hello, world!")); } EOF
aclocal && autoconf ./configure --host=i686-pc-mingw32 && make ./hello.exe