> 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.
>> 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 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
_______________________________________________
fedora-mingw mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
