My use case is building and testing software packages on Wine. My 32-bit build of wine-1.5.19 on x86_64 hardware was fine for this purpose for MinGW/MSYS builds so I stuck with it until today when I attempted to expand my building and testing of software to the Cygwin on Wine platform.
I immediately ran into some issues with the Cygwin setup.exe installer so my first instinct was to try the latest experimental wine release, wine-1.5.30, but it's build has changed quite a bit since when I built wine-1.5.19, and I need some help figuring out what to do.
The first issue was the configure script complained that the 32-bit version of the X libraries was missing and errored out. I then decided to try the 64-bit version of wine instead (since my Debian system has mostly 64-bit libraries). I got that 64-bit-only build and install to work perfectly, but I could not run anything with it.
For example:
wine@raven> wine64 wine64: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory
I then looked at http://wiki.winehq.org/Wine64 which recommended a WoW64 configuration, where you build both 64-bit and 32-bit versions of Wine and install both. So following those directions, the 64-bit version again built and installed without issues (in fact I just renamed what I did before) but the 32-bit version again errored out on lack of a 32-bit X library.
Now Debian wheezy has multiarch implemented properly for some (but not all) packages so I was able to install libx11-dev:i386 which coexisted fine with the installed libx11-dev:amd64 and also solved the 32-bit X issue. But then the 32-bit wine-1.5.30 configure continued further and ran into a similar issue with missing 32-bit freetype6. The error message was
configure: error: FreeType 32-bit development files not found. Fonts will not be built. Use the --without-freetype option if you really want this.
Accordingly I attempted to install libfreetype6-dev:i386 but on Debian wheezy that conflicts with libfreetype6-dev:amd64, and it appears the only way around this packaging issue for now (until the libfreetype6-dev:i386 and libfreetype6-dev:amd64 packages are taught to coexist) is to create a pure 32-bit Debian wheezy system (which I don't want to do).
So here are my questions and further comments:
1. Is there a way to stick with a pure 64-bit Wine system, or is that normally pretty useless because downloaded applications such as the Cygwin installer which apparently is 32-bit, i.e.,
wine@raven> file setup.exe setup.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows, UPX compressed
wont run on it?
2. If the WoW64 configuration is really the best solution, what are the consequences of dropping libfreetype from the 32-bit configuration (but obviously including it in the 64-bit configuration). IOW, if I just say --without-freetype for the 32-bit configuration (suggested as a possibility above by that error message) will the fonts be built and installed by the 64-bit configuration that includes libfreetype?
3. I would have liked to continue with pure 32-bit wine since that was what I have been used to all these years, but it appears wine-1.5.30 32-bit dependencies are really fearsome compared to the relative modest 32-bit dependencies for wine-1.5.19 so this effectively makes it impossible to build a standalone 32-bit wine system on Debian Wheezy (because no fonts will be built if --without-freetype is used) and might also compromise WoW64 builds (see question 2 above). It obviously doesn't affect pure 64-bit Wine builds, but I couldn't get that to work at all at run time (missing libwine.so.1 (see above)), but if there are workarounds for that issue, then it still might be useless (see question 1 above).
Any help/comments on the correct way to build wine-1.5.30 would be much appreciated for the case (as on Debian wheezy) where 32-bit and 64-bit libfreetype packages cannot be installed simultaneously.
Alan
__________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________