On 2013-05-21 21:22+0200 André Hentschel wrote:
To finally answer this: pure wine64 can't run 32-bit applications, you need wine32 or a wow64 setup for this.
Thanks for that important clarification. That means I always need 32-bit as standalone or as part of wow64. So regardless of that choice I have to figure out the 32-bit library configuration issues that have been introduced since wine-1.5.19.
To answer another responder (Ričardas Barkauskas), my system is almost entirely 64-bit with many 64-bit development packages installed so I can build lots of different 64-bit packages on Linux. But wine is the exception since from the above answer to my question, 32-bit wine is always going to be needed, and that requires installation of 32-bit libraries (which I only do because of my 32-bit wine needs).
Before, I straightforwardly built wine32 (e.g., for wine-1.5.19) with minimal issues with linking to a relatively small number of 32-bit libraries that were required at that time. However, somewhere between wine-1.5.19 and wine-1.5.30 (which I have patched as instructed for the libwine creation issue that came up early in this thread for 1.5.30) much more stringent requirements for 32-bit libraries were introduced for the 32-bit build, and this is a problem for Debian wheezy because many Debian wheezy library -dev packages (which create *.so symlinks to the shared libraries and which typically also provide static libraries) are not multiarch aware. The only way to beat this that I am aware of is convert to a 32-bit system (which I definitely don't want to do) or create the *.so symlinks to the 32-bit libraries myself. I have created a script to do that (in the user's standalone build tree to avoid contaminating system areas). After running that script (attached if anybody else reading this thread in the future finds it to be useful) I also execute
export LDFLAGS=-L$(pwd)
so those symlinks in the build tree are accessible to the linker.
The 32-bit wine-1.5.30 configure script results are now much better; I have reduced the number of missing 32-bit libraries from ~30 to 5. The associated configure messages are
configure: OpenCL 32-bit development files not found, OpenCL won't be supported. configure: libdbus 32-bit development files not found, no dynamic device support. configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled
configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported.
configure: WARNING: libpng 32-bit development files not found, PNG won't be supported.
At least I now have access to the 32-bit version of libfreetype which allows fonts to be generated. I did the normal 32-bit build after that configure step, and it looks like the result passes some minimal tests such as being able to run winecfg. However, when I tried running the Cygwin setup.exe from wineconsole, there were lots of warning messages about no png. As a result, I plan to work some more to get access to the 32-bit version of the png library before configuring and building the 32-bit version of wine-1.5.30 again.
If that search for a way to get access to the 32-bit png library is a success, the missing libraries will be reduced to 4. In the past for 32-bit builds I have gotten by without opencl and jpeg (according to my dated notes) so I am not going to worry about them (unless someone here advises me they have some importance I am unaware of).
Can somebody advise me about the importance (or not) of the remaining two missing 32-bit libraries (libdbus and gstreamer)? For example, are they worth some extraordinary measures such as downloading the binary i386 -dev package and extracting the static 32-bit versions separately from that package?
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 __________________________