Can I run the newest version of WINE on DragonFlyBSD?

[MACHINE <neo_match@xxxxxxxxxxx>]

Can I run the newest version of WINE on DragonFlyBSD?

From the link (http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD), I 
know WINE cannot run well on FreeBSD 4/5 due to VM issue.
So what about DragonFly?






http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD
-----------------------------------------------------------------
06/09/2004 	Wine on FreeBSD 	Archive
Ports

Remember last week how I alluded to a problem with Wine and FreeBSD? 
That thread began about a month ago and it started when John Birrell 
wondered how well Wine worked on FreeBSD-CURRENT (5.2.1) compared to 
-STABLE (4.10). Jonathan Fosburgh described the current (pun intended) 
situation, There is a threading problem right now (search the bug 
reports) on -CURRENT when using libpthread. Using libc_r is sort of 
working, at least as of a few weeks ago. I saw some discussion on one of 
the FreeBSD mailing lists discussing a different way of linking against 
a thread library that might make things work better. Basically, it 
involves not using -lpthread during the link stage but instead compiling 
against -pthread. Check through the freebsd-current and freebsd-ports 
mailing list archives, I believe the discussion was in one of those.

Gerald Pfeifer, the FreeBSD packager, then brought up the fact that 
-STABLE doesn't work either:

Right now, Wine doesn't work at all on FreeBSD -STABLE:

      wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap 
of entire address space failed: Cannot allocate memory

and before that I used to see deadlocks upon startup of non-trivial 
applications (such as Forte Agent, both 16bit and 32bit flavors).

I believe there are also significant threading issues on -CURRENT, so 
overall Wine is hardly, if at all, usable on any version of FreeBSD I 
have access to, even though I'm still working to keep it at least 
compilable on FreeBSD 4.9 and 5.2/5.3.

John then looked into the problem and reported what he found:

From what I can see, there are two problems with the Wine build from 
CVS on FreeBSD -current that seem to be related to the use of BSD make. 
In the dlls 'setupapi' and 'version' directories there are source files 
called install.c. These confuse the build during a "make install". BSD 
make tries to compile and link a program called "install". Renaming the 
source files to something other than install.c (such as winstall.c) 
allows the build to succeed.

At run time, the error:

      "wine: failed to initialize: /something/lib/wine/ntdll.dll.so: 
mmap of entire address space failed: Cannot allocate memory"

is caused by Wine attempting to mmap memory outside the user process 
address space. I see mmap addr around 0xd8100000 (mostly 0xd81eccd8) 
whereas the user address space limit on FreeBSD current is 0xbfc00000 
(at least on my system).

This failure is well before any thread library issues are encountered.

I ran a test of mmap on FreeBSD current to see what address space I was 
able to mmap. Using objdump to identify the pages that the test program 
was linked to load in, the test program was able to mmap MAP_ANON, 
MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc00000, except the 
pages at which the test program was mapped at.

I'll look further into how Wine is mmap'ing memory on FreeBSD.

Gerald then wondered where the change needed to be made - Wine or 
FreeBSD. John further explained:

From what I can see, the FreeBSD mmap address allocation behaviour that 
I see isn't documented. From the documentation, I would have expected 
the Wine code to work - it doesn't seem unreasonable to me.

I think the FreeBSD kernel code needs to change. If this is to happen, 
it will only be in the FreeBSD5 tree. It is too late in the FreeBSD4 
branch to make that sort of change since it's not really a bug fix.

To get Wine to work on FreeBSD4, there needs to be a way of making the 
reservation code optional. A simple mmap test in configure which 
snaffles memory above 0x80000000 and then tries to mmap some more memory 
without specifying a fixed address would detect if mmap is behaving in a 
way that would allow the Wine reservation code to function.

For FreeBSD5, which will become the stable branch sometime soon, I think 
the kernel code needs to change. I have a FreeBSD src commit bit, but 
I'm not a vm person, so I can only prototype a change and submit it for 
review. I'm not sure if the other developers will regard this change 
favourably, though. They may take the attitude that if Wine can be made 
to work with the FreeBSD kernel code as is, then Wine should be coded 
accordingly.

If the Wine code was restructured to make the reservation code optional, 
that would cover both FreeBSD4 and FreeBSD5. Then, if the FreeBSD mmap 
algorithm was to change in the future, the build could start using the 
reservation code at that time.

Alexandre didn't want that fix for FreeBSD4, Well, there's a reason for 
that reservation code, and it's that some Windows apps require it; so 
unless you find some other way to ensure that FreeBSD never allocates 
anything above 0x80000000, the reservation code can't really be made 
optional.

So... that was the status last month and no one has mailed the list to 
report any updates since then. If you're on FreeBSD 4.9, things will 
break if you upgrade to 4.10. If you're on 5.2 things are broken.