On Mon, Jul 27, 2009 at 02:50:58PM +0200, Paolo Bonzini wrote: > 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).
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. > 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? > 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. Which it should be. > 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. > 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]. [..] Let's step back here. What package are you trying to build? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw _______________________________________________ fedora-mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
