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
On Mon, Jul 27, 2009 at 08:37:39PM +0200, Paolo Bonzini wrote:
cat > configure.ac << \EOF AC_INIT AM_PATH_GLIB_2_0(2.0.0) AC_OUTPUT(Makefile) EOF
Just use PKG_CHECK_MODULES instead, as in the attached example. It works fine.
Now please answer my question:
Which package are you trying to build?
Rich.
On 07/28/2009 10:30 AM, Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 08:37:39PM +0200, Paolo Bonzini wrote:
cat> configure.ac<< \EOF AC_INIT AM_PATH_GLIB_2_0(2.0.0) AC_OUTPUT(Makefile) EOF
Just use PKG_CHECK_MODULES instead, as in the attached example. It works fine.
Richard, you miss the real problem, which is legacy. We can patch every AM_PATH_GLIB_2_0 to PKG_CHECK_MODULES for everything we package. We cannot expect users to know this.
Besides, AM_PATH_GLIB_2_0 will detect mismatched header files vs. installed libraries, while PKG_CHECK_MODULES, so your solution is not 100% equivalent.
Now please answer my question:
Which package are you trying to build?
Pick any one in this list:
http://www.google.com/codesearch?q=AM_PATH_GLIB_2_0 http://www.google.com/codesearch?q=AM_PATH_GTK_2_0
I could say xchat from latest CVS. (I did try to build it before writing this, and it failed).
Paolo
On Tue, Jul 28, 2009 at 10:57:57AM +0200, Paolo Bonzini wrote:
On 07/28/2009 10:30 AM, Richard W.M. Jones wrote:
On Mon, Jul 27, 2009 at 08:37:39PM +0200, Paolo Bonzini wrote:
cat> configure.ac<< \EOF AC_INIT AM_PATH_GLIB_2_0(2.0.0) AC_OUTPUT(Makefile) EOF
Just use PKG_CHECK_MODULES instead, as in the attached example. It works fine.
Richard, you miss the real problem, which is legacy. We can patch every AM_PATH_GLIB_2_0 to PKG_CHECK_MODULES for everything we package. We cannot expect users to know this.
Besides, AM_PATH_GLIB_2_0 will detect mismatched header files vs. installed libraries, while PKG_CHECK_MODULES, so your solution is not 100% equivalent.
So far, in us packaging about 100 packages (many dependent on glib), this has not proved a problem.
There's no issue with mismatching headers and libraries because everything is installed via RPM.
Now please answer my question:
Which package are you trying to build?
Pick any one in this list:
http://www.google.com/codesearch?q=AM_PATH_GLIB_2_0 http://www.google.com/codesearch?q=AM_PATH_GTK_2_0
I could say xchat from latest CVS. (I did try to build it before writing this, and it failed).
So xchat, specifically, is the package that you tried to make?
I will have a look at it later, but I'm quite busy on real work today.
Rich.
AM_PATH_GLIB_2_0 will detect mismatched header files vs. installed libraries, while PKG_CHECK_MODULES, so your solution is not 100% equivalent.
So far, in us packaging about 100 packages (many dependent on glib), this has not proved a problem.
Because you do not have Wine installed, so that check is not run. A user (not a fedora packager) will have it 99% of the time.
There's no issue with mismatching headers and libraries because everything is installed via RPM.
If you do not fix bug 513825, the configure script will get the Linux pkg-config, not the cross pkg-config. Then it will definitely report (if you have Wine installed, and with today's Fedora 11) mismatched headers and libraries.
Do you want me to prepare a screencast?!?
Now please answer my question:
Which package are you trying to build?
Pick any one in this list:
http://www.google.com/codesearch?q=AM_PATH_GLIB_2_0 http://www.google.com/codesearch?q=AM_PATH_GTK_2_0
I could say xchat from latest CVS. (I did try to build it before writing this, and it failed).
So xchat, specifically, is the package that you tried to make?
Yes.
Paolo
Op dinsdag 28-07-2009 om 11:19 uur [tijdzone +0200], schreef Paolo Bonzini:
AM_PATH_GLIB_2_0 will detect mismatched header files vs. installed libraries, while PKG_CHECK_MODULES, so your solution is not 100% equivalent.
So far, in us packaging about 100 packages (many dependent on glib), this has not proved a problem.
Because you do not have Wine installed, so that check is not run. A user (not a fedora packager) will have it 99% of the time.
That's strange. I do have wine installed here (with the binfmt stuff enabled) and I've never seen that behaviour when using ./configure --host=i686-pc-mingw32
There's no issue with mismatching headers and libraries because everything is installed via RPM.
If you do not fix bug 513825, the configure script will get the Linux pkg-config, not the cross pkg-config. Then it will definitely report (if you have Wine installed, and with today's Fedora 11) mismatched headers and libraries.
The rename of mingw32-pkg-config to i686-pc-mingw32-pkg-config is something I think we all agree of. However, we don't have any influence on the contents of the .pc files produced by packages. To get the sysroot part operational we need a lot of manual fiddling in all generated .pc files and a fully coordinated mass-rebuild. Both of which I'm sure the Fedora-MinGW32 packages aren't really interested in. And even if we have prepared all the packages and done a mass-rebuild, it'll still be a pain in the ass to maintain as it's easy to break or to forget to patch new .pc files.
Regards,
Erik van Pienbroek
AM_PATH_GLIB_2_0 will detect mismatched header files vs. installed libraries, while PKG_CHECK_MODULES, so your solution is not 100% equivalent.
So far, in us packaging about 100 packages (many dependent on glib), this has not proved a problem.
Because you do not have Wine installed, so that check is not run. A user (not a fedora packager) will have it 99% of the time.
That's strange. I do have wine installed here (with the binfmt stuff enabled) and I've never seen that behaviour when using ./configure --host=i686-pc-mingw32
Do you have glib2-devel? That's needed for the bug to trigger for my demo.
Also, you need very up-to-date libglib2. glib2 was updated to a newer 2.20.z release after F11, but mingw-glib2 wasn't.
Do you want me to prepare a screencast?!?
Might be a good thing
I was serious, actually. :-)
Paolo
Op dinsdag 28-07-2009 om 12:39 uur [tijdzone +0200], schreef Paolo Bonzini:
AM_PATH_GLIB_2_0 will detect mismatched header files vs. installed libraries, while PKG_CHECK_MODULES, so your solution is not 100% equivalent.
So far, in us packaging about 100 packages (many dependent on glib), this has not proved a problem.
Because you do not have Wine installed, so that check is not run. A user (not a fedora packager) will have it 99% of the time.
That's strange. I do have wine installed here (with the binfmt stuff enabled) and I've never seen that behaviour when using ./configure --host=i686-pc-mingw32
Do you have glib2-devel? That's needed for the bug to trigger for my demo.
Also, you need very up-to-date libglib2. glib2 was updated to a newer 2.20.z release after F11, but mingw-glib2 wasn't.
I just tried to reproduce your testcase and I see the problem. However, I don't blame the Fedora-MinGW toolchain for this, but just the fact that the AM_PATH_GLIB_2_0 macro (provided by /usr/share/aclocal/glib-2.0.m4 / glib2-devel) isn't cross-compile aware. It provides an option called --disable-glibtest to disable the runtime tests, but it isn't activated when a cross-compile is requested.
The test program itself which is used in that macro is also not platform-independent as it depends on a binary tool called 'touch' being be available on the platform which obviously isn't the case for Win32.
The best place to get this fixed would be in glib2 itself, not here.
Most (if not: all) other packages which use GLib use the PKG_CONFIG_CHECK macro to find out if glib is installed and whether the version of it is recent enough. It looks like X-Chat is just one of the few programs which has been using the AM_PATH_GLIB_2_0 macro. AFAIK none of the packages in our MinGW toolchain appear to use this macro. Perhaps you might want to patch X-Chat so that PKG_CONFIG_CHECK is used instead of AM_PATH_GLIB_2_0.
Regards,
Erik van Pienbroek
On 07/28/2009 01:28 PM, Erik van Pienbroek wrote:
by /usr/share/aclocal/glib-2.0.m4 / glib2-devel) isn't cross-compile aware. It provides an option called --disable-glibtest to disable the runtime tests, but it isn't activated when a cross-compile is requested.
AM_PATH_GLIB_2_0 supports cross-compilation. It uses PKG_PROG_PKG_CONFIG (so it will find i686-pc-mingw32-pkg-config correctly). And for a *real* cross-compile it works even if you don't pass --disable-glibtest: the AC_RUN_IFELSE does have a cross-compilation case that assumes everything tests okay.
The root cause (I wouldn't say the root problem; you can construe it as a bug or a feature) is that cross_compiling=no when using Wine.
Regarding the usage of touch, that's bug 513824. Actually, on reading the code of AM_PATH_GLIB_2_0, I'm actually not sure whether the lack of "touch" is important as long as the rest of the test program runs okay (which means as long as it finds pkg-config correctly, on which we agreed).
The best place to get this fixed would be in glib2 itself, not here.
Sure. But we'd have to deal with legacy packages not updating their autoconf macros literally for years, and with dead packages not being released anymore and keeping the old macros.
It looks like X-Chat is just one of the few programs which has been using the AM_PATH_GLIB_2_0 macro.
The GIMP is another one, and the Google code searches I gave have thousands of results. As I said, AM_PATH_GLIB_2_0 does have some advantages over PKG_CHECK_MODULES. If it didn't, the glib maintainers could have removed the --enable-glibtest code altogether.
Paolo
Op dinsdag 28-07-2009 om 15:26 uur [tijdzone +0200], schreef Paolo Bonzini:
The best place to get this fixed would be in glib2 itself, not here.
Sure. But we'd have to deal with legacy packages not updating their autoconf macros literally for years, and with dead packages not being released anymore and keeping the old macros.
For such packages an 'autoreconf' should suffice. Nevertheless, we (the Fedora MinGW SIG) can't help you with getting any changes to the /usr/share/aclocal/glib-2.0.m4 file in the distribution. For that you should propose a patch to the native glib2 maintainers or even better: directly upstream (so it ends up in Fedora after a short while)
Regards,
Erik van Pienbroek
On 07/28/2009 03:43 PM, Erik van Pienbroek wrote:
Op dinsdag 28-07-2009 om 15:26 uur [tijdzone +0200], schreef Paolo Bonzini:
The best place to get this fixed would be in glib2 itself, not here.
Sure. But we'd have to deal with legacy packages not updating their autoconf macros literally for years, and with dead packages not being released anymore and keeping the old macros.
For such packages an 'autoreconf' should suffice.
Should is the keyword, but fair enough.
Nevertheless, we (the Fedora MinGW SIG) can't help you with getting any changes to the /usr/share/aclocal/glib-2.0.m4 file in the distribution.
No, I would like the Fedora MinGW packages to just work instead. As far as I'm concerned, if glib-2.0.m4 works under Windows, it should work under Fedora MinGW32 + Wine too.
It's quite a dead end though, because right now sys-root is not a proper sysroot but it's hard to make it so without properly making it work in Libtool. If you can fix pkg-config's naming, I'd already be grateful.
I guess all I can do is document what I did to work around behavior that (IMHO) is buggy, in case other people try to compile GNU Smalltalk (or X-Chat :-) under Fedora MinGW.
I'll also open a bug in glib/gtk to prevent them from using touch.
Paolo
On Tue, 2009-07-28 at 11:19 +0200, Paolo Bonzini wrote:
Do you want me to prepare a screencast?!?
Might be a good thing 8-)
Whenever I start packaging something, I don't use mock, just rpmbuild, on a machine with wine installed. I haven't noticed any problem so far. ("something" included gtk gui applications)
Tom