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 __________________________
On 2013-05-20 20:24-0700 Alan W. Irwin wrote:
[...]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 fixed this 1.5.30 issue by applying the patch at
http://source.winehq.org/git/wine.git/patch/ce4b6451aabbe83809c7483c748cfa00...
as suggested by Hugh McMaster
and then redid the WoW64 build recommended by http://wiki.winehq.org/Wine64
For the 32-bit part of that, I tried the --without-freetype option to get round the problem that the two libfreetype6-dev:i386 and libfreetype6-dev:amd64 packages cannot be installed simultaneously for Debian wheezy. This allowed the configuration to finish with a long shopping list of missing 32-bit development packages. Those appeared not to be fatal unlike the missing 32-bit freetype development package which indeed turned out to be fatal. Here is that error message:
wine@raven> wineconsole setup.exe err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting
So here are my questions and further comments:
- 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?
I would appreciate an answer to this question, and if the answer is a standalone wine64 build should work, how do you run the above setup.exe?
- 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?
I believe I have answered this one above. Apparently it is still fatal even though the fonts were (presumably) built and installed for the 64-bit part of the WoW64 build since that had access to the installed 64-bit libfreetype development package.
- 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).
So it appears a pure 32-bit build or WoW64 build of (patched) wine-1.5.30 is completely blocked because of the fatal lack of 32-bit libfreetype library on Debian wheezy that can coexist with the 64-bit version of libfreetype. This was not an issue for my previous 32-bit build of wine-1.5.19. There remains a faint hope that a pure 64-bit build and install of wine-1.5.30 will work since there are no missing dependencies, and the pure 64-bit build and install finishes without errors. But I will need some guidance in that case about how to use such a pure 64-bit wine at run time to execute, say, the 32-bit setup.exe.
Hugh McMaster's reply was already a help, but I need more comments please.
For example, is there a patch that I could apply to get rid of the fairly new constraint for 32-bit builds that there must be a 32-bit libfreetype development package installed?
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 __________________________
On Tue, May 21, 2013 at 10:10 AM, Alan W. Irwin irwin@beluga.phys.uvic.cawrote:
Hugh McMaster's reply was already a help, but I need more comments please.
Maybe http://wiki.winehq.org/WineOn64bit could help?
Frédéric
On 2013-05-21 11:08+0200 Frédéric Delanoy wrote:
On Tue, May 21, 2013 at 10:10 AM, Alan W. Irwin irwin@beluga.phys.uvic.cawrote:
Hugh McMaster's reply was already a help, but I need more comments please.
Maybe http://wiki.winehq.org/WineOn64bit could help?
The idea there to install *.so symlinks manually might be a big help. For example, Debian wheezy does allow simultaneous install of libfreetype6:i386 and libfreetype6:amd64. (In fact, my system has those both installed now.) It is the -dev versions of those packages which cannot be simultaneously installed on Debian Wheezy. So the appropriate symlink may be all I need (for quite a few packages where the i386 library is installed, but not the -dev version with the symlink).
I will try this symlink idea (which takes me back to my first Linux install in 1996) later today after I get some sleep.
Thanks, Frédéric! I think this might work.
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 __________________________
The idea there to install *.so symlinks manually might be a big help. For example, Debian wheezy does allow simultaneous install of libfreetype6:i386 and libfreetype6:amd64. (In fact, my system has those both installed now.) It is the -dev versions of those packages which cannot be simultaneously installed on Debian Wheezy. So the appropriate symlink may be all I need (for quite a few packages where the i386 library is installed, but not the -dev version with the symlink).
I will try this symlink idea (which takes me back to my first Linux install in 1996) later today after I get some sleep.
Thanks, Frédéric! I think this might work.
Alan __________________________ Alan W. Irwin
If you don't care about building anything 64 bit installing pkg-config:i386 while removing pkg-config:amd64 allows for libfreetype6-dev:i386 and libfontconfig1-dev:i386 to be installed without playing with symlinks. (Though maybe 64 bit building stuff still works after this? )
REalm
Am 21.05.2013 10:10, schrieb Alan W. Irwin:
On 2013-05-20 20:24-0700 Alan W. Irwin wrote:
So here are my questions and further comments:
- 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?
I would appreciate an answer to this question, and if the answer is a standalone wine64 build should work, how do you run the above setup.exe?
To finally answer this: pure wine64 can't run 32-bit applications, you need wine32 or a wow64 setup for this.
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 __________________________
On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
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?
For your purposes, libdbus/gstreamer probably aren't important.
You should be aware that cygwin doesn't work terribly well under Wine, however. There are several open bugs: http://bugs.winehq.org/show_bug.cgi?id=12104 http://bugs.winehq.org/show_bug.cgi?id=19800 http://bugs.winehq.org/show_bug.cgi?id=19801 http://bugs.winehq.org/show_bug.cgi?id=19858 http://bugs.winehq.org/show_bug.cgi?id=19859 http://bugs.winehq.org/show_bug.cgi?id=21424 http://bugs.winehq.org/show_bug.cgi?id=24018
-- -Austin
On 2013-05-21 18:27-0700 Austin English wrote:
On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
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?
For your purposes, libdbus/gstreamer probably aren't important.
You should be aware that cygwin doesn't work terribly well under Wine, however. There are several open bugs: http://bugs.winehq.org/show_bug.cgi?id=12104 http://bugs.winehq.org/show_bug.cgi?id=19800 http://bugs.winehq.org/show_bug.cgi?id=19801 http://bugs.winehq.org/show_bug.cgi?id=19858 http://bugs.winehq.org/show_bug.cgi?id=19859 http://bugs.winehq.org/show_bug.cgi?id=21424 http://bugs.winehq.org/show_bug.cgi?id=24018
Thanks, Austin, for that additional information. In light of that information I will just ignore libdbus/gstreamer and concentrate on configuring access to 32-bit png.
The above list of cygwin-related issues seems pretty serious. I ran into the setup.exe problem detailed by 24018 myself for wine-1.5.19 and also my latest 32-bit build attempt (without png) of wine-1.5.30. I don't know how to work around 24018 (if that is even possible) due to my lack of Cygwin experience so I couldn't evaluate the other Cygwin issues detailed above.
This is my first experience with Cygwin (I only wanted to use it to test software builds like was so successful for me with MinGW/MSYS under wine-1.5.19). However, in light of the above issues and my lack of experience with Cygwin, I have decided to give up on Cygwin for now and just continue with MinGW/MSYS builds and tests of my software projects under Wine. Of course, even for that case the wine-1.5.30 build issues that are the subject of this thread are still relevant so I will continue with trying to figure out the png 32-bit library issue and ultimately try to see whether I can obtain similar success for my MinGW/MSYS software builds and tests under wine-1.5.30 like I currently experience with wine-1.5.19.
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 __________________________
-
Alan W. Irwin -
André Hentschel -
Austin English -
Frédéric Delanoy -
Ričardas Barkauskas