Bug 513819 - mingw directory not visible as a wine DOS path
Summary: mingw directory not visible as a wine DOS path
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: wine
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Andreas Bierfert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 513824
TreeView+ depends on / blocked
 
Reported: 2009-07-26 10:47 UTC by Paolo Bonzini
Modified: 2009-09-09 14:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-09 14:10:15 UTC


Attachments (Terms of Use)
configure script testing for glib (104.05 KB, text/plain)
2009-07-26 10:47 UTC, Paolo Bonzini
no flags Details
FYI configure.ac script used to generate configure (82 bytes, text/plain)
2009-07-26 10:48 UTC, Paolo Bonzini
no flags Details

Description Paolo Bonzini 2009-07-26 10:47:31 UTC
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

Comment 1 Paolo Bonzini 2009-07-26 10:48:32 UTC
Created attachment 355189 [details]
FYI configure.ac script used to generate configure

Comment 2 Paolo Bonzini 2009-07-26 10:54:57 UTC
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.

Comment 3 Paolo Bonzini 2009-07-26 11:01:19 UTC
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

Comment 4 Erik van Pienbroek 2009-07-26 16:23:05 UTC
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.

Comment 5 Richard W.M. Jones 2009-07-26 17:57:18 UTC
> 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").

Comment 6 Paolo Bonzini 2009-07-26 19:03:22 UTC
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).

Comment 7 Paolo Bonzini 2009-07-26 19:07:14 UTC
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.

Comment 8 Thomas Sailer 2009-07-26 20:12:54 UTC
(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.

Comment 9 Richard W.M. Jones 2009-07-26 20:40:48 UTC
(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.

Comment 10 Thomas Sailer 2009-07-26 20:50:26 UTC
> 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).

Comment 11 Paolo Bonzini 2009-07-27 06:58:45 UTC
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).

Comment 12 Richard W.M. Jones 2009-07-27 08:48:32 UTC
> 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.}

Comment 13 Richard W.M. Jones 2009-09-09 14:10:15 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.