From Wine-Wiki

Contents 1 Introduction 1.1 Requirements 1.1.1 Printing Support 1.1.2 Supported Applications 1.2 Troubleshooting FreeBSD 1.2.1 Sound 1.3 Win98 Mode 1.3.1 Breakages or problems noticed on the Mailing lists for Building on FreeBSD

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.

M. Wysocki [Dec08]: The wine version in their ports tree is from 1999 or so. [He then tried compiling] using gmake instead of make seems to fix [a] problem, apart from the missing ENOTSUP define in libs/port/spawn.c Ill report an update. once the build is done or failed. [Update] even with gmake the build did fail with exactly the same error message

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+

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,

A. English Dec 08: I tried getting it to work on OpenBSD as well, but couldn't get the [.] thing to install on virtualbox. I tried with a downloaded VM, but couldn't get a proper desktop setup (gnome wouldn't install for whatever reason). If someone can point me toward an OpenBSD install guide (for virtualbox), I'll get some OpenBSD bugs filed...

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

Supported Applications

See here for instructions on installing MS Office 2000 under FreeBSD

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".

G. Pfiefer [Jan 09] FreeBSD 8 is seeing a major rewrite of the arp code which removed the RTF_LLINFO flag and thus broke Wine, among others, see http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020464.html and the follow-ups for details. [He then proposed a patch to fix wine]

Sound

one mention on sound was here http://bugs.winehq.org/show_bug.cgi?id=15710

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

Breakages or problems noticed on the Mailing lists for Building on FreeBSD

Dec 08 wine devel Some of us on wine-users are trying to get Wine to install on OpenBSD. First, of course, we need to get it to compile on OpenBSD ... Are bugs on this platform considered valid reportable bugs?

A. english: File bugs on compiling issues, if you're sure they're bugs in wine and not bugs in OpenBSD. [..] FWIW, I'm working on trying this, but installing it in VirtualBox gives segfaults galore.

D. Gerard: State of things: it doesn't compile cleanly yet, and ./configure seems to fail to recognise a lot of libs that are in fact present. OpenBSD basically doesn't work properly in a lot of VMs because it is serious about not letting programs misbehave in ways that could cause insecurities. In the case of VirtualBox, OpenBSD not working has been acknowledged by the VirtualBox developers as "known bug, our emulation's imperfect, no paying customers affected [..] I'm currently playing with it in QEMU - don't try this with kqemu, that's known to break OpenBSD too! - and reliably geting the ENOTSUP compile-time error (which I'm about to file a bug on). I'll be getting a spare dual AMD64 next week to try it on OpenBSD under 32-bit and 64-bit. Dec 08 Winehq Bugzilla entry 16023: A developer wrote:The main reason the reservation code is still disabled on FreeBSD is because mmap(NULL) only tries addresses after the executable + some malloc heap space. Wine is located at 0x7bf00000. The heap size is currently set to 0x02000000 by the wine-freebsd loader, which is thought to be the absolute minimum required to support FreeBSD 6, where malloc doesn't fall back on mmap if it runs out of this heap space. It's not enough to run certain games for instance. Although I suspect there are memory leaks in certain DRI drivers, these games do run with a much larger heap space, like 512MiB. Anyway, so mmap(NULL) looks for free memory after about 0x7e000000. If you reserve everything beyond the 2GiB user space limit, that means there's about 32MiB left for all mmap(NULL) calls that might exist in code outside Wine, like for instance the ELF loader. A large portion of that 32MiB is already taken by DSOs.

A. Julliard wrote: Yes, but the point is that we don't want DSOs (at least not the Wine ones) to end up above 0x80000000, that's why we have the reservation code, and that's why it needs to be enabled on FreeBSD too. If there isn't enough space for DSOs below 0x80000000 this needs to be fixed.

T. Coosman: I wrote down a few things to get a bit of an overview. If there's anything wrong or if something can be done differently please say so.

These are the things related to mmap:

• location of executables, DSOs (*.dll.so *.exe.so, *.so)
• thread stacks
• malloc heap spaces

These are the things outside wine that use mmap:

• ELF loader calls mmap syscall directly.
• libc malloc calls internal libc mmap.
• DSOs can call libc mmap(2), but could also call the syscall.
• Stack allocation by libpthread. Inside Wine, stack allocation can be controlled by setting thread attributes in the argument to pthread_create(3), but threads could be created in code outside Wine as well.

Different mmap implementations:

• Allocate from the main stack downwards. (Linux)
• Allocate from the program start address+malloc heap upwards. (*BSD)
• Allocate randomly.(SELinux?)

Other observations:

• Wine wants to control at least the lower 2GiB of address space, but preferably even more to support 3GiB aware processes (?).
• Some .dll.so files have a specific image base address, and all of them are best allocated below 0x80000000 (at least for processes that aren't 3GiB aware).
• Most ELF loaders don't support base addresses for DSOs. AFAIK only the glibc loader in combination with prelink. (It's possible that linking DSOs as an ELF executable type can trick some loaders into supporting it, but this isn't portable.)
• At thread creation/destruction libpthread calls into the ELF loader to allocate/deallocate thread local storage for symbols that have been declared with __thread. These functions are essentially private and OS specific.

Consequences:

• You can't control all mmap calls (for instance by overriding/wrapping the libc mmap symbol).
• To support the random mmap you need something like wine-preloader which preserves all the regions Wine wants to control before any DSO ends up there.
• To support .exe.so and .dll.so base addresses Wine needs its own ELF loader or a .exe.so/.dll.so loader as a wrapper around the OS ELF loader.
• If Wine has its own .dll.so loader anyway it can make sure they all end up below 0x80000000 independent of the OS ELF loader capabilities and mmap implementations.
• The Wine loader (wine-pthread/kthread) could then be located at around 0xa0000000 for instance instead of 0x7bf00000 now, leaving plenty of space up to the main stack for all mmap calls outside Wine. [ed. update. wine announcement approx may 09 notes - Get rid of the no longer supported wine-kthread. http://www.winehq.org/announce/1.1.17 ]
• Everything before the Wine loader can be preserved by wine-preloader and can be used by the Windows process. Wine would keep track of used/free regions and always call mmap with a specific address and MAP_FIXED. Beware of multiple threads here. Never call munmap.

About the .exe.so/.dll.so loader:

• Because libpthread calls into the OS ELF loader, that one will still have to be around and to support __thread symbols in code outside Wine all standard .so libraries need to be loaded by it.
• So, any dependencies that are standard .so libraries would have to be loaded using the dlopen/dlclose/dlsym API.
• If __thread is used in .dll.so or .exe.so, Wine needs to wrap thread creation/destruction to call into the .dll.so loader which can allocate/deallocate the memory for those symbols.

A. Julliard: Providing an ELF loader in Wine is not a realistic option. It would need to interact with the system loader using internal interfaces that are not exported and not supposed to be used from applications. Fixing the memory reservation code on FreeBSD is trivial by comparison.

T. Coosmans: I just don't think you can get the reservation code working satisfyingly without moving wine-pthread lower. Introducing a .dll.so loader would really release a lot of the constraints Wine currently tries to fit in and solve the -image-base problem at the same time. And as far as I can see it can be done in a portable way. It would handle .dll.so completely and the system loader would never know about them. Normal .so libraries can be handled through dlopen/dlsym. Most of them are already dlopen'ed anyway.

Pfeifer:Would it make a significant difference if we were to require a minimum of FreeBSD 7.0? If so, that might be an option with the release of 7.1 pending.

A. English posted a comment by A Suslikov: randomized mmap is not only for SELinux but also for OpenBSD. [for more read the bug report]

T. Coosmans: But to clarify a few things, the preloader and the ELF loader are different things. The wine-preloader already exists for Linux (loader/preloader.c). It's a static program that reserves some memory regions that are important to Wine and then loads the actual Wine program. The ELF loader I'm suggesting would be to allow Wine to load .dll.so libraries in the way it wants to independent of the system ELF loader.

F. Gouget: (http://bugs.winehq.org/attachment.cgi?id=18355) posted a patch to Reenable the memory reservation code on FreeBSD I did not test this patch at all on FreeBSD (I don't have access to a FreeBSD machine right now), but it's a simple tweak of the previous memory reservation patch. Applied alone it breaks threading. But combined with the patch to pthread.c it should get things working again on FreeBSD and seems nearer the to right way to fix things than my previous attempt.

A. English posted a comment by Suslikov (OpenBSD Wine port maintainer) "Also, can you comment in 16023 and point to a patch in 16666 which disables linking with -Wl,--section-start,.interp=0x7bf00400 in order to bring wine close to a working state on OpenBSD. I believe it is related to what Tijl describes as "-image-base problem". Please refer to http://www.openbsd.org/papers/rp2007-slides.pdf wrt OpenBSD's ld.so which

• load libraries at random memory locations,
• load libraries in random order.

I think this is important in context of ELF loader discussion in 16023." The patch he's referring to is: http://bugs.winehq.org/attachment.cgi?id=18415

F. Gouget: -- Now that Alexandre has fixed the big threading roadblock by allocating the thread stack in ntdll, my patch to reenable the memory reservation gets Wine working again 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:

• http://wiki.freebsd.org/Wine

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