Free BSD
From Wine-Wiki
Contents |
[edit] Introduction
Recently [Nov 08] Dan Kegel asked for help with [[patchwatcher a script that checks patches by running the wine tests before they get into wine. If someone wants it checking patches for breakages on BSD, they should contact him.
This is a compilation of comments taken from the Wine mailing lists. All comments here should not be taken as advice but rather as a starting point for further research. You are welcome to add advice, but please add the month and year [eg [Sept 06]] so people can note how recent it was updated.
WINE can be compiled from ports in /usr/ports/emulators/wine
The FreeBSD version -usually- is in sync with the current one and are available here http://www.freshports.org/emulators/wine/
M. Hearn [May 05]: As far as I'm aware there are still problems with the threading on this platform.
S. fourman jun 08 wine devel: FreeBSD does a pretty good job of keeping its ports tree updated with the latest wine release. wine gets released every other Friday, and usually by Sunday the new release hits the ports tree. it is as simple as
portupgrade -ar
in my experience wine runs really well in FreeBSD 7+
[edit] Requirements
[link lost] WINE will only work correctly with the FreeBSD 5.x tree and only versions newer than 5.3 M. Meissner [Sept 06 updated the wine readme - you should read it in full]: FreeBSD info: Wine should build on FreeBSD 4.x and FreeBSD 5.x,
[edit] Printing Support
[Link lost 06?] The default package will NOT compile with CUPS support, so printing will be disabled. This is because the Makefile looks for the CUPS libraries in /usr/include/cups but they exist in /usr/local/include/cups. To enable CUPS printing, create the following link.
ln -s /usr/local/include/cups /usr/include/cups
[edit] Supported Applications
See here for instructions on installing MS Office 2000 under FreeBSD
[edit] Troubleshooting FreeBSD
T. Coosman [Sept 07 wine bug 9581]: the FreeBSD ports system strips binaries by default. If you want a more useful backtrace you can build and install the Wine port using "make WITH_DEBUG=yes install".
[edit] Win98 Mode
T. Coosmans [Jul 06]: For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf00000. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x80000000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x20000000. That would be the easiest solution by far, but, are there any potential problems with that?
A. Julliard:that's too low, apps can expect that address to be free. If you can't change the 512Mb thing then you should use something around 0x50000000, but really the 0x70000000 range would be preferable.
T. Coosmans then tried: I lower RLIMIT_DATA to 0x18000000 (384Mb) in wine-glibc and locate wine-pthread at 0x64000000. Is this an acceptable location? There has to be enough room after wine-pthread + data segment for every lib and dlopen'ed object. Moreover, the data segment can't be too small because it's the malloc heap and the limit is inherited by the wineserver process. So this is a bit of a balancing act.
A. Julliard: it would be preferable to set a much lower limit and raise it again before starting wineserver. Otherwise it creates a big range of memory that will be inaccessible to Windows apps, and force us to relocate pretty much all native dlls. [The discussion continued further] wine achive
[edit] Breakages or problems noticed on the Mailing lists for Building on FreeBSD
Sept 07 A problem with winecfg is apparently being worked on[ wine bug 9581]: The bug report noted update to 6-STABLE and see if the problem has been fixed there or not? There have been a couple bug fixes to the virtual memory subsystem (c0000005 means memory access violation) in the last couple of weeks. Be sure to also use the 6-STABLE patch from the wiki then. Then he added: Oh, I thought you had 6.2-RELEASE. In that case, could you update to today's STABLE? The bug reporter noticed:
err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems
after stumbling on this, I've enabled GLX extension on my X (which thanks to old uninstalled nvidia drivers was not loading), and the problems disappeared, both on notepad.exe and other applications.
Aug 07 A Problem was reported with compiling Wine of FreeBSD amd64 in Bug 9457. Comment #2 from Dmitry Timoshkov: Looks like configure.ac in Wine has support for building a 32-bit binary under Linux (look for x86_64*linux*) but not under FreeBSD. A patch was tried without success. A. Julliard: 2007-08-26: It looks like the port is passing incorrect flags to configure, the cpu name should be x86_64, you should report this to the port maintainers. In any case building on 64-bit won't do what you want, and last I heard FreeBSD doesn't support 32-bit cross compilation.
Jun 07
K. Blin: There is actually a couple of FreeBSD people working on this. However, this needs some kernel level fixes in FreeBSD, so I don't know if we will see Wine working on 6.x. The fix is on it's way into the 7.x codebase, as far as I am aware. [wine bugs jun 07] However another added to the bug report: I've been told Warcraft 3 is working again on FreeBSD kernel 6.2 using wine-kthread. But there are still other problems
A developer reported a problem with running some software: I notice that FreeBSD ports only has 0.9.36, but the web site shows 0.9.38 as being the latest release ... could it be a difference between those two versions? After further checking he reported: Just built 0.9.38 under FreeBSD, and it doesn't even run Never a good sign ... but explains why the port is 2 releases old ...
K. Blin: two days ago, I've sent the following email to the freebsd-hackers mailing list: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020761.html
M. Founier: Let me read through your email and see if I can nudge some comments out of some of the 'kernel developers' that I know, who might be able to help shed some light ... or at least get us moving forward ...
K. Blin: Thanks for the help, I really appreciate it.
G Pfeifer: I debugged this a bit, and believe the change that broke FreeBSD is revision 1.82 of dlls/ntdll/thread.c and related patches to other files. [the mailing list discussion ended there]
May 07 K. Moore: We're looking for a Wine dev to assist us with some porting issues over to PC-BSD / FreeBSD. We've recently begun to embrace making packages with wine embedded, making the process of loading windows programs a snap. The end user only needs to double-click, insert their CD, and click next a few times. This allowed us to make some packages for programs such as PhotoShop & Dreamweaver which even a non-linux/BSD user could install. We really want to expand these packages, to include things such as games, and others, but there are a few problems with running Wine on BSD at the moment. If anybody is willing to help us out with this, please let me know! Here's a list of some of the porting issues were aware of:
Sept 06 A programmer reported: I get the following error running configure on FreeBSD:
config.status: creating Makefile sed: 14: ./confstathEGAkR/subs-4.sed: unescaped newline inside substitute pattern
There's one of those for every Makefile. The problem is with the following lines in configure.ac where I had to add '\\' to every line to work around the problem. Is this a FreeBSD only thing?
- AC_SUBST(DEPENDENCIES,"### Dependencies:\\ \\
- .INIT: Makefile\\
- .BEGIN: Makefile\\
- Makefile: dummy\\
- -\$(MAKEDEP) -C\$(SRCDIR) -S\$(TOPSRCDIR) -T\$(TOPOBJDIR) \$(EXTRAINCL)
- \$(DEPEND_SRCS)\\
- \\
- \$(ALL_OBJS): \$(IDL_SRCS:.idl=.h)\\
- \$(LEX_SRCS:.l=.yy.o): \$(LEX_SRCS:.l=.yy.c)\\ \$(BISON_SRCS:.y=.tab.o):
- \$(BISON_SRCS:.y=.tab.c)")
M. Meissner: No, I see it in all older SUSE Versions too...
April 2006
G. Pfiefer: I now get the following build error on FreeBSD 5.4: undefined reference to `GetCharABCWidthsI' After the change to dlls/gdi/font.c by julliard. gdi: Added implementation of GetCharABCWidthsI. A fix was made to CVS as he then reported: Last night's automated builds now went fine again,[...] on FreeBSD 5.4
wine archive
July 05 Compile error with mscms
../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./mscms.spec handle.o icc.o mscms_main.o profile.o stub.o transform.o mscms.dll.dbg.o version.res -o mscms.dll.so -L../../dlls -L../../dlls/kernel32 -L../../dlls/ntdll -lkernel32 -lntdll -L../../libs/wine -lwine -L../../libs/port -lwine_port profile.o: In function `OpenColorProfileW': /test/wine/dlls/mscms/profile.c:786: undefined reference to `cmsOpenProfileFromMem' /test/wine/dlls/mscms/profile.c:835: undefined reference to `cmsOpenProfileFromMem' [...] collect2: ld returned 1 exit status winegcc: /sw/gcc-3.3.4/bin/gcc failed. gmake: *** [mscms.dll.so] Error 2
H. Liedekker: You have the lcms headers but somehow linking against lcms fails on your system. Can you find out why? Jacek had traced this problem to a 64-bit version of lcms on his system. [He then posted a Patch to fix your compile problems but until the linking problem is addressed, the mscms dll would be non functional]
G. Pfiefer: I found that on that test system lcms was installed in /usr/local:
- /usr/local/include/lcms.h
- /usr/local/lib/liblcms.a
- /usr/local/lib/liblcms.so
- /usr/local/lib/liblcms.so.1
The compiler considers /usr/local/include for include files, but later the compiler/linker then fails to consider /usr/local/lib for libraries. Thanks a lot for the quick response and patch! I'm happy to confirm that the patch indeed addresses the build problem on that test system. The FreeBSD port of Wine in the FreeBSD Ports Collection will consider /usr/local so the users shall get the extended functionality.Image:Example.jpg
