Created attachment 355187 [details] configure script testing for glib Description of problem: The cross-compilation packages install DLLs into /usr/i686-pc-mingw32/sys-root/mingw/, but these are not visible from Wine. This is a problem when running programs that use those libraries (including configure scripts that detect the libraries!). I am reporting this as a wine bug because it is possible to fix it in wine: - patch wineprefixcreate to symbolically link /usr/i686-pc-mingw32/sys-root/mingw/ to "$WINEPREFIX/dosdevices/c:/mingw" - patch /usr/share/wine/wine.inf so that it prepends "C:\mingw\bin;C:\mingw\lib;" to the value of the PATH key in HKLM\System\CurrentControlSet\Control\Session Manager\Environment Version-Release number of selected component (if applicable): 1.1.23 How reproducible: Always Steps to Reproduce: 1. install mingw-gcc, mingw-gtk2, and non-mingw glib 2. run the attached configure script. GLib is detected. 3. now run it with --host=i686-pc-mingw32 Actual results: GLib is not detected, and a long error message is printed. Expected results: GLib is installed and should be detected by configure scripts Additional info: Error message: checking for GLIB - version >= 2.0.0... *** 'pkg-config --modversion glib-2.0' returned 2.20.4, but GLIB (2.20.1) *** was found! If pkg-config was correct, then it is best *** to remove the old version of GLib. You may also be able to fix the error *** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing *** /etc/ld.so.conf. Make sure you have run ldconfig if that is *** required on your system. *** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH *** to point to the correct configuration files no *** Could not run GLIB test program, checking why... *** The test program compiled, but did not run. This usually means *** that the run-time linker is not finding GLIB or finding the wrong *** version of GLIB. If it is not finding GLIB, you'll need to set your *** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point *** to the installed location Also, make sure you have run ldconfig if that *** is required on your system *** *** If you have an old version installed, it is best to remove it, although *** you may also be able to get things to work by modifying LD_LIBRARY_PATH
Created attachment 355189 [details] FYI configure.ac script used to generate configure
Note that broken symlinks are hidden completely from the user, so the user would have the problem of seeing this confusing behavior: C:\>dir Volume in drive C is Volume Serial Number is 0000-0000 Directory of C:\ 6/27/2009 11:12 PM <DIR> Program Files 6/27/2009 11:12 PM <DIR> users 7/26/2009 11:54 AM <DIR> windows 0 files 0 bytes 4 directories 32,132,485,120 bytes free C:\>mkdir mingw C:\>dir Volume in drive C is Volume Serial Number is 0000-0000 Directory of C:\ 6/27/2009 11:12 PM <DIR> Program Files 6/27/2009 11:12 PM <DIR> users 7/26/2009 11:54 AM <DIR> windows 0 files 0 bytes 4 directories 32,132,485,120 bytes free (i.e. directory not created). To work around this, it should be possible to create the mingw sysroot directory and its bin/lib subdirectories in the wine package.
An alternative way to test this is to compile this program: #include <glib.h> int main() { char *test = g_strdup("Ok."); puts (test); } using i686-pc-mingw32-gcc f.c -I /usr/i686-pc-mingw32/sys-root/mingw/include/glib-2.0/ -I /usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include -lglib-2.0 Without the steps above, it prints err:module:import_dll Library libglib-2.0-0.dll (which is needed by L"Z:\\home\\pbonzini\\a.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\pbonzini\\a.exe" failed, status c0000135
I don't think of this as a real bug. The Fedora-MinGW SIG has created an environment where it is possible to cross-compile packages on a Fedora Linux host for Win32 targets. Wine isn't needed to cross-compile packages. Wine is just used to test the generated binaries (but most people perform the real tests on native Win32 environments). When using the autotools to cross-compile packages the runtime-specific tests are skipped (in some cases you need to manually create a config.cache file like mentioned at http://library.gnome.org/devel/glib/stable/glib-cross-compiling.html). The same probably also applies to other build systems (I'm not really familiar with those..) so wine isn't needed to compile mingw packages. Wine's behaviour when executing programs which depend on other (cross-compiled) libraries is the same as would happen on real Windows environments. That is: only the default paths and the current path are searched for libraries. For example, if you copy your a.exe to /usr/i686-pc-mingw32/sys-root/mingw/bin and execute 'wine ./a.exe' the program should run just fine. Developers/packager who wish to create win32 installers containing cross-compiled binaries are adviced to bundle all the dependent binaries in the installer and install them all in the same path. In the past there have been attempts to install GTK in a generic location (like the Gladewin32 project: http://gladewin32.sourceforge.net/) but AFAIK pidgin is the only user of it and the gladewin32 packages are outdated anyway.
> This is a problem when running programs that use those libraries (including > configure scripts that detect the libraries!). We build many packages that depend on previously built packages (several layers deep), all using autoconf, and it all works fine. I would agree with Erik, that this is not a bug. Also Wine should never be used when compiling packages. Any package that needs runtime tests using Wine is clearly broken (read the autoconf info file "6.6 Checking Runtime Behavior").
There are three problems: 1) when given --host, Autoconf tries to run a program to determine if you're cross compiling. If you have Wine installed the Windows executable are registered with the kernel binfmt_misc module and then you're not cross-compiling, or at least Autoconf doesn't think you are. So glib will run the runtime tests that detect mismatches between the versions in the include files and the actual library versions. While I agree that necessary runtime tests are evil, they can be useful when they are supported because they are more precise that compile-only tests. Indeed in my case it detected that I was using the wrong pkg-config (bug 513825). That's why it is ok to report this as a wine bug, also. The bug doesn't happen if Wine is not installed. 2) The reason GNU Smalltalk's build needs Wine is not needing runtime tests, but rather that it needs to run itself to complete the build. This is not related to this bug. > Wine's behaviour when executing programs which depend on other (cross- > compiled) libraries is the same as would happen on real Windows environments. > That is: only the default paths and the current path are searched for > libraries. I know, but this bug applies to uninstalled binaries. It is currently impossible to run a quick-and-dirty glib/gtk program in Wine except by manually adding c:\mingw\bin to the path. (BTW, I stand corrected; adding c:\mingw\lib is not required).
I forgot the third problem. 3) The cross-compilation environment is obviously not enough to run "make check". This is a good reason to install Wine and thus fall prey of item (1) above.
(In reply to comment #6) > 2) The reason GNU Smalltalk's build needs Wine is not needing runtime tests, > but rather that it needs to run itself to complete the build. This is not > related to this bug. This won't currently work anyway. MinGW packages are noarch. koji builders will select any free builder, and often use ppc or ppc64 builders. On ppc machines, wine will not work. So if you want this to work, you need to file an RFE for koji.
(In reply to comment #8) > This won't currently work anyway. MinGW packages are noarch. koji builders will > select any free builder, and often use ppc or ppc64 builders. On ppc machines, > wine will not work. So if you want this to work, you need to file an RFE for > koji. Actually there's an even more fundamental problem - Wine requires an X server and a $HOME directory to function, and for those reasons I never managed to get it to run under Koji (even using Xvfb). (In reply to comment #6) > 2) The reason GNU Smalltalk's build needs Wine is not needing runtime tests, > but rather that it needs to run itself to complete the build. This is not > related to this bug. I'm guessing this is a bootstrapping problem - ie. the Smalltalk compiler/runtime is written in Smalltalk, so must be compiled using Smalltalk. We have other packages like this (certainly mingw32-ocaml, possibly our Tcl package too). The standard solution is to BuildRequire the *native* package, and use that to run the bits that need to be run during the build. With OCaml this was especially complex, but that's what we did.
> Actually there's an even more fundamental problem - Wine > requires an X server and a $HOME directory to function, and > for those reasons I never managed to get it to run under > Koji (even using Xvfb). You don't necessarily need an X server, I successfully use wine with a windows console application without X (just unset DISPLAY before calling wine).
Wait wait, we're talking about two different things. I'm not talking about packaging GNU Smalltalk for Fedora. I'm talking about developing Windows programs on Linux using MinGW and Wine, and the problems I had with it *while trying it out on GNU Smalltalk*. (Don't be confused by my @redhat.com; this is not something I'm doing for my job). > I'm guessing this is a bootstrapping problem - ie. the Smalltalk > compiler/runtime is written in Smalltalk, so must be compiled > using Smalltalk. Yes, it runs the VM executable to compile the runtime. It would be possible to do as said in comment #9 (the output file is the same for i686-linux and i686-mingw32,some files are even the same for all architectures), or just to BuildRequire the native package and copy bits from its /usr/share and /var/lib into the target package. But let's not get distracted from the main issue, which is about interactions between wine (which makes the i686-pc-mingw32 not really a cross compiler anymore) and the cross compilation environment. Wine and a cross-compiler will not really be installed together by Koji, but they definitely will be together on a Fedora user's machine (such as me).
> 1. install mingw-gcc, mingw-gtk2, and non-mingw glib Hmmm - I don't really care what happens when you install a "non-mingw glib". Use our mingw32-glib. > 1) when given --host, Autoconf tries to run a program to determine if you're > cross compiling. If you have Wine installed the Windows executable are > registered with the kernel binfmt_misc module and then you're not > cross-compiling, or at least Autoconf doesn't think you are. This is a real bug (with autotools). I've raised it with Jim Meyering some time ago. No one has found a good way to fix it, but the workaround is to kill Wine's binfmt_misc handler before running the configure script. > [Smalltalk] Please take a look at how we built mingw32-ocaml. {BTW this should be discussed on the mailing list, because discussing it in Bugzilla entries is hard to follow, and while there may be bugs, I'm not convinced there is a 1-1 correspondence between bugs and the four Bugzillas that happen to be opened now.}
I can't see that there's a real bug here. If you want to suggest ways to improve the MinGW packaging, then please discuss it on the list. You might also want to try out any ideas by reproducing our smock build environment, which will let you build all ~200 MinGW packages.