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
> 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.
> 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.
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
> 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
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
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?
(*) Try it yourself. Install wine, glib2-devel, mingw-glib2, and run
cat > configure.ac << \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)
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)
cat > hello.c << \EOF
printf ("%s\n", g_strdup ("Hello, world!"));
aclocal && autoconf
./configure --host=i686-pc-mingw32 && make