I386 Building from source
From Wine-Wiki
Contents |
[edit] Introduction
While the source files come with a README file which details a customized Wine installation script called wineinstall, this is the old way to install wine.
./tools/wineinstall
This is mostly, but not exactly, the usual ./configure && make && sudo make install .
./configure && make depend all && sudo make install
Now it appears you just use the usual configure, make and install.
Hiji [Oct 05]: For me, I've had to make sure cups-devel is installed before I compiled Wine. This would allow the printers to show up.
J. Green [Mar 06]: wine will compile and run without a lot of features and never warn you that they don't exist. See this [official] wiki page for an example of what your include/config.h file should probably look like: http://wiki.winehq.org/Recommended_Packages wine archive
A Julliard 2008-04-09 --- I've enabled the <daily> snapshot feature in gitweb, we'll see if it overloads the server
kernel version: M. Meissner [Sept 06 updated the wine readme]: While Linux 2.2.x should still work and Linux 2.0.x may still work (older 2.0.x versions had thread-related crashes), it's best to have a current kernel such as 2.4.x or 2.6.x.
[edit] Troubleshooting Building from Source
A user asked: Where do i download the tarball?
You can download it to any folder you want.
Hiji: extract the tarball into the directory of your choice. Then, within that, navigate to the "tools" folder and run the "wineinstall" script as a regular user. It will take care of everything for you; all you need to do is answer its questions. When you run wineinstall, it will eventually ask for your su password to complete the installation.
[This appears no longer necessary. Just run the normal commands as shown below:]
M. Duarte Wine Archives: If is a clean install, [...], a
cd wine ./configure make depend && make su -c "make install"
should be ok. Configure generates the make rules.
When something is broken, A. English suggested [winebug 9707 Sept 07]: Run ./configure --verbose and make sure you have met _all_ needed dependencies.
R. Shearman [Sept 07] pointed to a valuable link: http://wiki.winehq.org/Recommended_Packages
A user [dec 05] reported
/_/usr/local/bin/wine: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory_
M. Hearn: If you have /etc/ld.so.conf.d, run these commands as root:
- echo '/usr/local/lib' >/etc/ld.so.conf.d/usr-local.conf/
- sbin/ldconfig
You can tell if you have an /etc/ld.so.conf.d directory by doing a "cd" into it, if it works you have it, if you get an error you don't. If you don't have /etc/ld.so.conf.d run these commands as root:
- echo '/usr/local/lib' >>/etc/ld.so.conf
- /sbin/ldconfig
Then try again. wine archive
A user noted:
/usr/bin/ld: cannot find -lcapi20 collect2: ld returned 1 exit status
D. Skorka -l capi20 means 'link with the library called capi20'. You don't have it installed. Search the packages for your distribution. wine archive
[edit] Troubleshooting Configure Options
A programmer tried
- ./configure --without-opengl
but noticed [May 06]: After this the wined3d.dll.so is left on the disk.And if later I run the game again via vnc server, I get weird errors and see Wine crashing in wined3d.dll (and sometimes wineprefixcreate crashes inside shlwapi.dll or opengl.dll). [...] Shouldn't configure delete dlls/wined3d/wined3d.dll.so or unlink dlls/wined3d.dll.so or at least define code don't try loading wined3d.dll when "--without-opengl" option is given to it?
E. Pouech: The configure system is not robust enough to allow the changes you're talking off. If you change the options passed to ./configure, then you need to rebuild everything from scratch. Period. Make distclean is even preferable to make clean. Another options is to have one compilation directory for each set of options to configure you want to use (assuming you're running wine from the build tree). wine archive
[edit] Compiler Flags
A. Julliard [Dec 06] was asked: "Is there a compiler flag that you use to cause warnings?". He replied:
- -Wcast-qual.
That's what all the recent patches from Andrew Talbot are about, to make it possible to turn this on by default. wine archive
A post [Nov 2005] to the list showed someone having some difficulty:
A programmer posted: you probably should pin it down a bit more precisely before reporting it. You should also look at gcc doc to see what all these things mean before playing with them. http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/i386-and-x86-64-Options.html#i386%20and%20x86-64%20Options
McCormack: If somebody wants to report that an unsupported flag makes Wine not work, then he should figure out the exact patch and flag combination that caused the regression, and that's the information that should be posted to WineHQ. [...] The way developers recommend compiling Wine is explained in the README file. [...] Using any compiler flags other than what configure adds by
default is unsupported, untested and unreliable. Even seemingly harmless flags such as "-Wall" cause trouble.
D. Timoshkov: When somebody plays with compiler flags [...] If you are brave enough to use custom compiler switches you are must be qualified enough to cope with any problems caused by that. [...However in this case] It's most likely that -fomit-frame-pointer is the culprit.
P. Beutner: -fomit-frame-pointer is [...] in general safe to use for 90% of applications out there( it basicly only prevents that you get some useful debug traces, by saving a few instructions) And [...] it used to work in wine [...] Until some days ago.
M. Meissner: The problem could be a patch, or it could be something else. While -fomit-frame-pointer is a no-risk option in other programs, this is not the case for WINE. [...] Because we call binary code. And occasionaly this code assumes values in the %ebp register. The best example is EXC_CallHandler() for instance, where windows code looks at the %ebp framechain.One reason [why] it is implemented in assembler now. So please try current CVS after Robs last patch has been applied.
M.cCormack highlighted that because Wine is not version 1 yet, but rather has only recently reached 0.9 debugging is important: I think turning off the debugging features of Wine isn't such a great idea, and not something that should be encouraged. The more people that do that, the more useless crash reports Wine developers will get. [..] (it basicly only prevents that you get some useful debug traces, by saving a few instructions) wine archive
Undefined reference
> ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole > encode.o protectdata.o testlist.o -o crypt32_test.exe.so > -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 > -L../../../libs -lcrypt32 > encode.o(.text+0x38): In function `func_encode': > /home/phantom/src/wine/dlls/crypt32/tests/encode.c:56: undefined > reference to `CryptEncodeObjectEx' > encode.o(.text
M. Meissner[Jun 05]: This is a temporary problem.[He then pointed out how to fix..]
cd dlls rm *.def cd .. make
Uninstalling when the Source Tree was Removed
A user had difficulty removing a previous install as: The source tree was removed long ago so I couldn't do a make uninstall.
However: I did remember that the build drops the files in a /usr/local directory if you you a default configuration. I ran a rpm -q --list on then new wine and then removed all the named files from /usr/local/bin and /usr/local/lib. Additionally I performed a rm -r on the /usr/local/lib/wine directory. This fixed it since /usr/local/... has precedence over /usr/lib and /usr/bin. Wine Archives
error you must implement the interlocked* functions for your CPU
A user reported when interlocked.c was compiled on his IBM zSeries s/390 the following message appears: "error you must implement the interlocked* functions for your CPU".
V. Margolen [sept 05]: That means that this function is not implemented for your platform. It's only a first from lots more that are not implemented. [...]Pull out your book on what ever CPU it's using and start coding. ;-) Wine Archive
Further Reading
- http://source.winehq.org/source/libs/port/interlocked.c
- http://www.winehq.org/?issue=168#MacOS%20X%20Work
Openldap
The latest [sept 05] version of wine (both CVS and tarball) doesn't compile on my machine (2.6.13 kernel, gcc 3.3.4). I get an error in dlls/wldap32:
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: parse error before "BerElement" winldap_private.h:290: error: parse error before "BerElement" winldap_private.h:322: error: parse error before "BerElement" winldap_private.h:323: error: parse error before "BerElement"
J. Ernst: You need to have openldap headers or use this patch: http://bugs.winehq.org/show_bug.cgi?id=3265
The user reported the problem still occoured, but then realized why: My mistake, previously I've forgotten to re-configure it. Now, after re-running ./configure, it compiles correctly. Wine Archive
Another user reported this was shortly afterward fixed in CVS: Current CVS worked like a charm, thanks!
Wine cannot find the FreeType font library.
A user ran into this curious error [Oct 05]: Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5.
D.Kegal: The first clue was funny output from Wine's configure script, though it was hard to see until I diff'd against good output, and used cat -v to make invisible chars visible:
... +checking for ldd... /home/mmoss/bin/ldd +checking for -lX11 soname... libX11.so.6^[[0m +checking for -lXext soname... libXext.so.6^[[0m
And what's that funny ldd? And what are those escape sequences? Turns the ldd is one wrapped by acoc (http://www.caliban.org/ruby/acoc.shtml) which colorizes the output, which also explains the funny escape sequences. This error went away when we stopped using acoc to colorize the output of commands like ldd. We had been using acoc-0.5.2, but the latest version (0.7.1) also exhibits the problem. wine archive
[edit] Breakages Compiling Wine Releases
S. Richie gave a tip for when wine fails to compile [Dec 05]: Are you certain you have all the build dependencies? (Check configure's output)
Occasionally there is a breakage and we try to make a note of them here. You should be using the latest version, but if there is some concern about updating or you have to use an older vesion this may be of some use.
Jul 06
Been running 0.9.15 for a while without problems. Since a week ago (or so)when I updated to HEAD, all I get from Wine is this:
- wine-git # notepad
- Segmentation fault
They then found running make clean before reinstalling wine fixed the problem (ie.not a wine fault) wine archive
darckness: the source tarball [0.9.17] up on sourceforge right now is corrupt/incomplete and will not work. A. Julliard quickly noted: It's fixed now wine archive
Jun 06
device.c:3833: `GL_FOG_COORD_SRC' undeclared (first use in this function)
H. Verbeet: Could you try the attached patch? It adds and uses the defines as defined in the extension (http://oss.sgi.com/projects/ogl-sample/registry/EXT/fog_coord.txt), rather than the ones from OpenGL 1.5. If it works I'll submit it to wine-patches. James reported: compile works with this patch applied. Thanks. wine archive
May 06
baseshader.c: In function `print_glsl_info_log': baseshader.c:688: error: `GL_OBJECT_INFO_LOG_LENGTH_ARB' undeclared (first use in this function)
J. Huizer: I had this one too; well if it's possible you could get cvs of today, the problem seems to be fixed
Dec 05
wine archive
cubetexture.c: In function 'IWineD3DCubeTextureImpl_GetCubeMapSurface': cubetexture.c:276: error: 'D3DCUMPMAP_FACE_POSITIVE_X' undeclared (first use in this function) cubetexture.c:276: error: (Each undeclared identifier is reported only once cubetexture.c:276: error: for each function it appears in.)
After a clean and cvs -PAd a user reported the following errors during make
netconnection.c: In function `sock_get_error': netconnection.c:205: error: `EINTR' undeclared (first use in this function) netconnection.c:205: error: (Each undeclared identifier is reported only[...]
He then noted: I didn't have the openssl development headers and as a previous post mentioned Robert Shearman made a change that requires them. R. Shearman: That was an oversight on my part. If you use the recently sent patch by Patrick Ammann it should compile again without the openssl headers. wine archive
Nov 05
value.c: In function `bv2str': value.c:123: error: dereferencing pointer to incomplete type value.c:128: error: dereferencing pointer to incomplete type value.c: At top level: value.c:135: warning: 'bv2str_array' defined but not used make[2]: *** [value.o] Error 1 make[2]: Leaving directory `/home/storri/src/wine/dlls/wldap32' make[1]: *** [wldap32] Error 2 make[1]: Leaving directory `/home/storri/src/wine/dlls' make: *** [dlls] Error 2
J. Ligget: A patch to fix it was submitted to wine-patches, but it hasn't been committed yet: http://www.winehq.com/pipermail/wine-patches/2005-November/022242.html wine archive
Users with unstable versions of important programs often report difficulties
[Nov 05] a user reported that a recent change in glibc (features.h) broke [configure]... but according to time.h, CLK_TCK is obsolete, and CLOCKS_PER_SEC is to be used instead.
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o time.o time.c time.c: In function TIME_ClockTimeToFileTime: time.c:522: error: CLK_TCK undeclared (first use in this function) time.c:522: error: (Each undeclared identifier is reported only once time.c:522: error: for each function it appears in.) make[2]: *** [time.o] Error 1
When asked about which version M. Meissner: glibc HEAD CVS (upcoming 2.4 release if it ever happens).
[edit] Building from source with GCC4
M. Meissner: [Dec 05]: [Wine currently] works fine on gcc 4.0, gcc 4.1 and also current 4.2 development branch.wine archive
Building Wine using GCC4 is regularly tested as explained by M. Meissner [May 05]: I regulary compile WINE with gcc 4 HEAD CVS and gcc 4.0 branch and I know some others do too.
A user reported [Aug 05]: I updated my Fedora 4 setup with a new version of gcc (4.0.1 instead of 4.0.0), then compiled a vanilla 2.6.12 kernel and the Wine CVS tree.[...]I would recommend staying away from gcc 4.0.0 and update to 4.0.1 or higher before compiling Wine. Wine Archive
[edit] Troubleshooting Building from source with GCC4
Preloader.c:863
A User reported [Jun05]: [Wine Archives] I hate bothering the -devel list with compile errors, [...and wondered] if anyone else [was] using gcc4..
preloader.c: In function =E2=80=98is_in_preload_range=E2=80=99: preloader.c:863: error: =E2=80=98union <anonymous>=E2=80=99 has no member= named =E2=80=98a_ptr=E2=80=99 preloader.c:864: error: =E2=80=98union <anonymous>=E2=80=99 has no member= named =E2=80=98a_ptr=E2=80=99 make[1]: *** [preloader.o] Error 1 make[1]: Leaving directory `/home/phantom/src/wine/loader' make: *** [loader] Error 2
Another reported: I get the same error on my Fedora Core 4 (t3+updates) install. When checking out current cvs I get this error:
make[2]: Entering directory `/usr/src/wine-cvs/wine/dlls/msdmo' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=3D2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o dmoreg.o dmoreg.c dmoreg.c:94: error: static declaration of =E2=80=98IID_IEnumDMO=E2=80=99 = follows non-static declaration ../../include/mediaobj.h:64: error: previous declaration of =E2=80=98IID_IEnumDMO=E2=80=99 was here dmoreg.c: In function =E2=80=98IEnumDMO_fnAddRef=E2=80=99: dmoreg.c:385: warning: pointer targets in passing argument 1 of =E2=80=98InterlockedIncrement=E2=80=99 differ in signedness [...] make: *** [dlls] Error 2
Further investigation found problem caused by a change with glibc: a_un.a_ptr no longer exists in the elf aux vector struct.
A. Mohr said [it would be good if they used] a magic keyword or similar mechanisms to mark elements scheduled for clean removal right before the next major version, and not [...] within almost the same version number [but then added..] OTOH projects have to do binary incompatible changes a bit before the release of the next major version, otherwise there won't be any testing. And perhaps glibc is in such a version change phase right now...
M Meissner submitted a fix that was accepted to cvs: Elf32_auxv_t.a_un.a_ptr no longer exists in HEAD glibc CVS, use a_val. Patch: http://cvs.winehq.org/patch.py?id=17873
Internal Compiler Error
>dialog.c: In function =E2=80=98msi_dialog_scrolltext_control=E2=80=99: > dialog.c:516: internal compiler error: in gimple_add_tmp_var, at > gimplify.c:532 > Please submit a full bug report, with preprocessed source if appropriate. > See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. > Preprocessed source stored into /tmp/cczY7yIu.out file, please attach this to your bugreport.
M. McCormack: This is a gcc bug. You should submit it to the bugzilla site above, not to wine-devel.
Known issues
- [Sept05] Wine built with GCC 4.0 breaks SecuRom protected games -- probably in signal handling [...though] this would likely be fixed soon. Wine Archive
- A programmer noticed a problem with GCC 4.01 and a miscompilation of user32.dll.so. The discussion led to further research.wine archive
[edit] Using Pre Releases of GCC
A user reported a problem with gcc 4.0.2.pre. However as a programmer pointed out: you're using unstable , pre-release compilers. Please dont waste time here. There enough true disfunctionality in Wine that needs to be tracked down and corrected without deliberately trying to break things. wine archive
