Winelib under Solaris/SPARC

[Robin KAY]

I would to like compile Winelib under Solaris/SPARC so that I can 
develop Windows applications from the relative comfort of UNIX, leaving 
only the final building and testing to real Windows running under Bochs. 
I have tested a selection of Wine releases and the build typically fails 
with either one of two errors. I used gcc 3.3.4 with the assembler and 
linker from binutils 2.15, and I configured the builds with:

LDFLAGS="-R/opt/csw/lib -L/opt/csw/lib" CPPFLAGS="-I/opt/csw/include" 
./configure --without-opengl

1) Releases between wine-20021125 and wine-20040121 (inclusive)

gcc -c -I. -I. -I../../include -I../../include -I/usr/openwin/include
-D__WINESRC__  -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-gstabs+ -Wpointer-arith -I/opt/csw/include -g -O2 -o ddraw.spec.o
ddraw.spec.c
{standard input}: Assembler messages:
{standard input}:1169: Error: operation combines symbols in different
segments
[snip]
{standard input}:2006: Error: operation combines symbols in different
segments
gmake[2]: *** [ddraw.spec.o] Error 1

An archived mailing list post suggested that this is caused by a failure 
to RTFM and configure the source tree to build winelib rather than plain 
wine with PE loader, however I haven't been able to find any 
documentation that supports this view. None of the releases I tested had 
a configure script which accepted --disable-emulator. The source file 
which causes this error varies with release.

2) Releases between wine-20040213 and wine-20040716 (inclusive)

../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ntdll.spec
    cdrom.o critsection.o debugbuffer.o debugtools.o directory.o env.o
error.o exception.o file.o heap.o large_int.o loader.o loadorder.o
misc.o nt.o om.o path.o process.o reg.o relay.o resource.o rtl.o
rtlbitmap.o rtlstr.o sec.o server.o signal_i386.o signal_powerpc.o
signal_sparc.o string.o sync.o version.o thread.o time.o virtual.o
wcstring.o relay32.o ntdll.dll.dbg.o   -o ntdll.dll.so -L../../dlls
-L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode
-L../../libs/port -lwine_port -R/opt/csw/lib -L/opt/csw/lib -lresolv
-lsocket -lnsl
ntdll.dll-DqmZVz.spec.c:20:1: warning: "__stdcall" redefined
<command line>:17:1: warning: this is the location of the previous
definition
thread.o(.text+0xc1c): In function `NtCurrentTeb':
/home/komadori/dev/stuff/wine-20040716/dlls/ntdll/thread.c:582:
undefined reference to `wine_pthread_get_current_teb'
collect2: ld returned 1 exit status
winegcc: gcc failed.
gmake[2]: *** [ntdll.dll.so] Error 2

I tried adding wine_pthread_get_current_teb to libs/wine/wine.def and 
libs/wine/wine.map, but this caused the resulting binaries to 
dereference a bad address in NtCurrentTeb.

This mail was origianally posted to comp.emulators.ms-windows.wine from 
where I was redirectled. Does anyone know how to fix these problems or 
if any of the older release tags in CVS will build under Solaris/SPARC? 
Thanks.

[Mike Hearn]

> I tried adding wine_pthread_get_current_teb to libs/wine/wine.def and 
> libs/wine/wine.map, but this caused the resulting binaries to 
> dereference a bad address in NtCurrentTeb.

wine_pthread_* functions are supposed to be defined in the 
wine-pthread/wine-kthread binaries. The DSOs then have their symbols 
resolved to the executable at runtime. I don't know why this isn't 
working for you but it's almost certainly related to using 
Solaris/SPARC. You'd have greater success running Linux I suspect, if 
it's just a UNIXish environment you're after .... though I'm not sure 
developing Windows software using Wine is a good plan anyway, you'd end 
up spending time fixing Wine bugs as well as writing your prorgams :)

thanks -mike

[Robin KAY]

Mike Hearn wrote:
> wine_pthread_* functions are supposed to be defined in the 
> wine-pthread/wine-kthread binaries. The DSOs then have their symbols 
> resolved to the executable at runtime. I don't know why this isn't 
> working for you but it's almost certainly related to using 
> Solaris/SPARC.

It looks like GNU binutils were at fault. I rebuilt gcc to use Sun's 
linker, fixed the bad flags specified for it in configure.ac, and wine 
builds without the error (not counting a bunch of other minor 
portability fixes to the tree). Of course, the binaries still segfault.

$ wineprefixcreate
$ winemine
Segmentation Fault - core dumped
$ gdb /usr/local/bin/wine core
GNU gdb 6.1
[snip]
Core was generated by `/usr/local/bin/wine winemine.exe'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libwine.so.1...done.
[snip]
Loaded symbols for /usr/local/lib/wine/kernel32.dll.so
#0  0xfec92814 in NtCurrentTeb () from /usr/local/lib/wine/kernel32.dll.so
(gdb) bt
#0  0xfec92814 in NtCurrentTeb () from /usr/local/lib/wine/kernel32.dll.so
#1  0xfec068c0 in __wine_kernel_init () at process.c:1016
#2  0xff04955c in __wine_process_init (argc=-16477044, argv=0xff3853d8)
     at loader.c:2057
#3  0xff384618 in wine_init (argc=1, argv=0x0, error=0xffbff0f8 "",
     error_size=1024) at loader.c:536
#4  0x00010fdc in main (argc=1, argv=0xffbff56c) at main.c:44
> You'd have greater success running Linux I suspect, if 
> it's just a UNIXish environment you're after ....

Or Solaris/IA32 for that matter. This is the only machine I have at the 
moment though.