Compile Wine 2.15 on Solaris 11.3

[solaris_user]

Hello,

Just one remark about the Wine compilation on Solaris.

I compiled and ran successfully Wine 2.15 on Solaris 11.3, using the GNU C compiler available on the Solaris official package repository (the old GNU GCC 3.4.3).

I had to remove some code in "dlls/ntdll/virtual.c" to avoid undefined variable error as presented below. The removed code is in comments:

void virtual_get_system_info( SYSTEM_BASIC_INFORMATION *info )
{
/*
#ifdef HAVE_SYSINFO
struct sysinfo sinfo;
#endif
*/
info->unknown = 0;
info->KeMaximumIncrement = 0; /* FIXME */
info->PageSize = page_size;
info->MmLowestPhysicalPage = 1;
info->MmHighestPhysicalPage = 0x7fffffff / page_size;
/*
#ifdef HAVE_SYSINFO
if (!sysinfo(&sinfo))
{
ULONG64 total = (ULONG64)sinfo.totalram * sinfo.mem_unit;
info->MmHighestPhysicalPage = max(1, total / page_size);
}
#endif
*/
info->MmNumberOfPhysicalPages = info->MmHighestPhysicalPage - info->MmLowestPhysicalPage;
info->AllocationGranularity = get_mask(0) + 1;
info->LowestUserAddress = (void *)0x10000;
info->HighestUserAddress = (char *)user_space_limit - 1;
info->ActiveProcessorsAffinityMask = get_system_affinity_mask();
info->NumberOfProcessors = NtCurrentTeb()->Peb->NumberOfProcessors;
}


The compilation error was:

virtual.c: In function `virtual_get_system_info':
virtual.c warning: implicit declaration of function `sysinfo'
virtual.c error: structure has no member named `totalram'
virtual.c error: structure has no member named `mem_unit'
*** Error code 1
make: Fatal error: Command failed for target `virtual.o'

I did not have any other compilation errors.

(additional note: as indicated in https://bugs.winehq.org/show_bug.cgi?id=37135, it is needed to run Wine like this: LD_PRELOAD=libumem.so UMEM_OPTIONS=backend=mmap wine )

[Bob Wya]

Good info! Wow that's an old version of gcc... Even older than Debian!

This forum has

Code: Select all

Code

tags - please use them in future!

Ta
Bob

[aimeec1995]

You should upload a binary and also attempt this on open indiana.
Does graphics work for it? Would be interesting to see a program like steam launching on it.

[solaris_user]

I only tested with MS Office 2007. Office works very well. I cannot create 64 bit wineprefix (only 32 bit wineprefix are created).

[Hark1medes]

I'd also be interested if you have any luck building Wine on a recent version of OpenIndiana, not that I have any experience with it. There used to be a lot more effort going into testing and hacking wine on Solaris, but obviously that died down when Sun was gobbled up and OpenSolaris was left to wander the wilderness.

If you come up with a lot of good advice and information though, feel free to share it. We used to have a separate page on the wiki for OpenIndiana, but it was only a stale stub page; you can also update some of the entries here:
https://wiki.winehq.org/Compatibility

I'm also not sure if the winetest server still accepts submissions run on Solaris, but that might be worth looking into.

[beben]

Building wine on OpenIndiana hipster works well, thanks to the work of the team.

I launched a few games like Anarchy Online, Silence, Dungeon Siege, SWTOR (wine-staging 3.5)...
Most of them are quite old games.

I attached the patches, they work for wine 3.5, most probably for 3.7 as well.
Just :
1) apply the patches and make sure /opt/gnu/bin is first in your PATH
2) ./configure CFLAGS=-std=gnu99 CXXFLAGS=-std=gnu99 LDFLAGS=-lumem --prefix=/opt/wine
3) gmake -j8
4) gmake install

export UMEM_OPTIONS=backend=mmap and enjoy

[beben]

Ok, it seems that uploading files is too difficult for me
Here are the patches :

Code: Select all

--- dlls/ntdll/file.c   2018-03-05 15:57:35.723531245 +0000
+++ dlls/ntdll/file.c   2018-03-05 15:58:52.947627428 +0000
@@ -24,6 +24,11 @@
 #include <stdio.h>
 #include <errno.h>
 #include <assert.h>
+
+#if defined(__sun) && defined(__SVR4)
+#include <limits.h>
+#endif
+
 #ifdef HAVE_UNISTD_H
 # include <unistd.h>
 #endif
--- dlls/ntdll/signal_i386.c    2016-12-24 08:52:13.000000000 +1300
+++ dlls/ntdll/signal_i386.c    2017-01-03 15:34:44.137167786 +1300
@@ -326,6 +326,10 @@
 #define gregs regs
 #endif

+#if defined(__sun) && defined(__SVR4)
+#include <sys/regset.h>
+#endif
+
 #define EAX_sig(context)     ((context)->uc_mcontext.gregs[EAX])
 #define EBX_sig(context)     ((context)->uc_mcontext.gregs[EBX])
 #define ECX_sig(context)     ((context)->uc_mcontext.gregs[ECX])
--- a/dlls/ntdll/virtual.c    2016-10-29 07:41:36.000000000 +1300
+++ dlls/ntdll/virtual.c       2016-11-01 16:39:30.588654079 +1300
@@ -1371,7 +1371,8 @@
 #ifdef HAVE_SYSINFO
     if (!sysinfo(&sinfo))
     {
-        ULONG64 total = (ULONG64)sinfo.totalram * sinfo.mem_unit;
+        //ULONG64 total = (ULONG64)sinfo.totalram * sinfo.mem_unit;
+        ULONG64 total = (ULONG64) 0;
         info->MmHighestPhysicalPage = max(1, total / page_size);
     }
 #endif

And of course, steam does work.

[Hark1medes]

Building wine on OpenIndiana hipster works well, thanks to the work of the team.

I launched a few games like Anarchy Online, Silence, Dungeon Siege, SWTOR (wine-staging 3.5)...
Most of them are quite old games.

I attached the patches, they work for wine 3.5, most probably for 3.7 as well.
Just :
1) apply the patches and make sure /opt/gnu/bin is first in your PATH
2) ./configure CFLAGS=-std=gnu99 CXXFLAGS=-std=gnu99 LDFLAGS=-lumem --prefix=/opt/wine
3) gmake -j8
4) gmake install

export UMEM_OPTIONS=backend=mmap and enjoy

Well, that's good news!

The last time I read about it, my impression was OpenIndiana needed years of work before it could run something as complex as Wine again. Looks like I was mistaken. So I checked into the details, and you can't run the wine test suite on a patched build (no mention of explicitly blacklisting Solaris / OpenIndiana though).

By any chance, has somebody tried submitting these patches to the developers' list, or even wine-staging? Especially if what you've posted here is everything, I don't see why it would be difficult to get them approved*. I mean, they're only touching 12 lines in 3 files, and your first two changes are just includes wrapped in precompiler ifs.

I'd think if the third patch used conditionals instead of commenting out the existing line, it would qualify for wine-staging at least. Now, I'm not sure which would be preferable, precompiler macros (probably?) or C if-statements, but either way doesn't look hard at first glance. The main issue might be if setting the "total" variable to 0 is too kludgy (I have no clue how it should ideally be set on OpenIndiana), but even that should be less an issue if you submit it to wine-staging at first. After that, some shell and environment subtleties might belong in the configure script, but if these are really the only steps, Wine would be back on OpenIndiana.

* I've never submitted patches for Wine itself so I'm quite possibly ignoring a swamp of details.

[beben]

Yes the last one, the line

Code: Select all

#ifdef HAVE_SYSINFO

can be replaced by

Code: Select all

#if defined(HAVE_SYSINFO) && !defined(__sun)

Rather than setting the totalram to 0

I just compiled 3.8 and wine-staging 3.8 and both works.

Please note that a very recent update on Openindiana killed it, wine now just segfault right away (even winefile or winecfg just segfault).

[Hark1medes]

I don't have a spare computer and don't want to get too crazy with this one so I don't have OpenIndiana installed. If you're willing to keep testing things though, maybe we can get this figured out.

Please note that a very recent update on Openindiana killed it, wine now just segfault right away (even winefile or winecfg just segfault).

Actually, I wonder if this is a result of the change you just tried. I think ntdll/virtual.c handles virtual memory management for Wine, and if that gets borked somehow, a segfault seems like the kind of thing it would let out. Of course, if winecfg / winefile don't piggyback off of wine itself, that shouldn't make a difference and the problem probably is in the newer build of OpenIndiana.

Either way though, since we still want to pass the original lines to the compiler if the build-target is something other than OpenIndiana, I think you'll want to go for something more like this (though I don't know whether the Wine devs allow nesting #ifs or the style convention if they do):

Code: Select all

#ifdef HAVE_SYSINFO
    if (!sysinfo(&sinfo))
    {
# ifdef __sun
        // Uncomment the next line if total isn't just for setting MmHighestPhysicalPage
        // ULONG64 total = (ULONG64) 0;
        info->MmHighestPhysicalPage = 1;  // This is almost definitely a kludge
# else
        ULONG64 total = (ULONG64)sinfo.totalram * sinfo.mem_unit;
        info->MmHighestPhysicalPage = max(1, total / page_size);
# endif
    }
#endif

This way if the precompiler sees you're not on Solaris/OpenIndiana, it uses the same code as before, but if it does see that __sun is defined, it will set MmHighestPhysicalPage to 1 (which was the ultimate result of your first patch).

[beben]

I think the right approach would rather be "if solaris/openindiana sysinfo doesn't comply to the mem stuff, let's just not set HAVE_SYSINFO for this platform" is a better way to do it.

But either way, your way or the "HAVE_SYSINFO AND not sun" way is good enough to compile and run things.

About the segfault, I suspect it is related to KPTI code which has been introduced lately in OpenIndiana, as the same binary works well with the previous kernel that I have. I tried to start on the recent kernel with KPTI code disabled but no cigar...

I should try to look with the devs but I can't seem to interact with the ML automaton, it's a blackhole.

[beben]

Forgot something: this is only 32bits wine as I haven't been able to build a 64bits version at all.

[Hark1medes]

I think the right approach would rather be "if solaris/openindiana sysinfo doesn't comply to the mem stuff, let's just not set HAVE_SYSINFO for this platform" is a better way to do it.

That's not a bad idea. I guess the only issue would be if sysinfo stores other useful records, besides the memory stuff. It would be much cleaner code-wise though.

About the segfault, I suspect it is related to KPTI code which has been introduced lately in OpenIndiana, as the same binary works well with the previous kernel that I have. I tried to start on the recent kernel with KPTI code disabled but no cigar...

I can't help you much there; any OpenIndiana specifics are beyond my pay-grade. It sounds like you know your way around it pretty well though. Likewise with the C programming; I wasn't sure how experienced you were from your first posts so sorry if I was being tedious.

I should try to look with the devs but I can't seem to interact with the ML automaton, it's a blackhole.

Do you mean the automatic emails to subscribe to the mailing list? I'm not sure about that specifically, but if you've already subscribed and your messages aren't getting through, try waiting until tomorrow to see if they suddenly show up. I had a really bad run-in with the mail-list last week, including the blackhole problem you described at one point. I still don't know what happened exactly. My best guess is that the ML spam filter had an allergic reaction to my submission, partly because I was using a less common domain. Of course YMMV.

Forgot something: this is only 32bits wine as I haven't been able to build a 64bits version at all.

Yeah, I wouldn't sweat that for now. It could be a kink in the wine code, in the build process, or a bug on OI's end. Whatever the cause though, it should be easier to figure out once the 32-bit version works.

[beben]

I've cleaned up a little bit things and here's the result for wine 3.8 on OpenIndiana Hipster

If you want wine-staging, apply staging patches first

then patch it for OpenIndiana
Patch to apply :

Code: Select all

--- dlls/ntdll/signal_i386.c    2016-12-24 08:52:13.000000000 +1300
+++ dlls/ntdll/signal_i386.c    2017-01-03 15:34:44.137167786 +1300
@@ -326,6 +326,10 @@
 #define gregs regs
 #endif

+#if defined(__sun) && defined(__SVR4)
+#include <sys/regset.h>
+#endif
+
 #define EAX_sig(context)     ((context)->uc_mcontext.gregs[EAX])
 #define EBX_sig(context)     ((context)->uc_mcontext.gregs[EBX])
 #define ECX_sig(context)     ((context)->uc_mcontext.gregs[ECX])
--- dlls/ntdll/virtual.c        2018-05-12 06:20:21.000000000 +0000
+++ dlls/ntdll/virtual.c        2018-05-22 14:00:17.283013377 +0000
@@ -1853,7 +1853,7 @@
  */
 void virtual_get_system_info( SYSTEM_BASIC_INFORMATION *info )
 {
-#ifdef HAVE_SYSINFO
+#if defined(HAVE_SYSINFO) && !defined(__sun)
     struct sysinfo sinfo;
 #endif

@@ -1862,7 +1862,7 @@
     info->PageSize                = page_size;
     info->MmLowestPhysicalPage    = 1;
     info->MmHighestPhysicalPage   = 0x7fffffff / page_size;
-#ifdef HAVE_SYSINFO
+#if defined(HAVE_SYSINFO) && !defined(__sun)
     if (!sysinfo(&sinfo))
     {
         ULONG64 total = (ULONG64)sinfo.totalram * sinfo.mem_unit;

then :
make sure you have /usr/gnu/bin first in you PATH
$ ./configure LDFLAGS=-lumem --prefix=/opt/wine
$ gmake -j4
# gmake install (as root)
$ export UMEM_OPTIONS=backend=mmap

NB : KPTI code seems to introduce some issues with Wine so it doesn't work with kernel including this code (whether you disable it or not).

[Hark1medes]

I've cleaned up a little bit things and here's the result for wine 3.8 on OpenIndiana Hipster

I like it, and I noticed you didn't have to touch file.c anymore either. I'd definitely try getting in touch with some of the developers, at least for wine-staging. I don't know how much of a project you wanted to make out of this, and I probably can't help much with runtime errors, but I'd think getting wine to build in OI is a good start.

However, I did try looking a little into how the code in virtual.c might eventually work like the non-Solaris code already does. This is just based on me trying to look through the illumos source code and other docs so you'll definitely want a second opinion, but my impression was that Illumos doesn't provide as much low-level detail through sysinfo as the other kernels. At the very least, only virtual memory info is defined with the actual sysinfo struct, nothing that appears to relate to physical memory:
https://github.com/illumos/illumos-gate ... /sysinfo.h

It looks like on Solaris / OpenIndiana, kstat is the preferred way to access that kind of information. kstat has a different design and provides statistics in a linked list, but there is a query function if your statistic has a name and you know what it is:
https://www.illumos.org/man/3KSTAT/kstat_lookup

I couldn't really find a big list of named statistics in one place though so it may just take some experimenting with kstat in the console. I found at least one StackOverflow question that does show you can inspect physical memory in Solaris that way:
https://unix.stackexchange.com/question ... ough-kstat

Of course, this is all further down the road. I imagine if you are interested in doing more, you would want to fix the runtime failure first.

[beben]

The current state is enough for me.

For the KPTI issue and of course the future of wine on OI/solaris, there is a bug report and the OI/Illumos dev are aware but the issue is only on wine and the community is quite small so I don't expect it to be solve quickly.

wine bug report is https://bugs.winehq.org/show_bug.cgi?id=45263