I've decided to try compiling Wine on the Sun SPARC station 4. This machine is running Debian Woody 3.0r2. I am first time Debian installer. Is it completely wrong idea? If no, then going next:
I've chose "C and C++ development" task and finished it (by tasksel), so all the related packages were installed.
Now, after the run of "./configure" I run "make depend" and get into trouble:
s2@austechia:/usr/src/wine-20040914$ make depend cd ./tools && make `basename tools/makedep` make[1]: Entering directory `/usr/src/wine-20040914/tools' gcc -c -I. -I. -I../include -I../include -DLEX_OUTPUT_ROOT=""lex.yy"" -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o makedep.o makedep.c In file included from makedep.c:23: ../include/wine/port.h:53: conflicting types for `mode_t' /usr/include/sys/types.h:71: previous declaration of `mode_t' ../include/wine/port.h:56: conflicting types for `off_t' /usr/include/sys/types.h:89: previous declaration of `off_t' ../include/wine/port.h:59: warning: redefinition of `pid_t' /usr/include/sys/types.h:99: warning: `pid_t' previously declared here ../include/wine/port.h:71: conflicting types for `fsblkcnt_t' /usr/include/sys/types.h:247: previous declaration of `fsblkcnt_t' ../include/wine/port.h:74: conflicting types for `fsfilcnt_t' /usr/include/sys/types.h:251: previous declaration of `fsfilcnt_t' make[1]: *** [makedep.o] Error 1 make[1]: Leaving directory `/usr/src/wine-20040914/tools' make: *** [tools/makedep] Error 2
I would like to find the primary reason of this, but am not sure about all the possible combinations of header files. Should I post the output of running ./configure?
On Tue, 12 Oct 2004, Saulius Krasuckas wrote:
I've decided to try compiling Wine on the Sun SPARC station 4. This machine is running Debian Woody 3.0r2. I am first time Debian installer. Is it completely wrong idea? If no, then going next:
I've chose "C and C++ development" task and finished it (by tasksel), so all the related packages were installed.
Hi Saulius,
did you apply some sun4* patch before ./configure and make ? I'd be glad to compile wine on my sun4u sun, too.
I have the following headers installed on my machine, that might help you: (don't know if all are required by wine)
ii develock-el 0.23-5 additional font-lock keywords for the develo ii dpkg-dev 1.10.23 Package building tools for Debian ii libc6-dev 2.3.2.ds1-16 GNU C Library: Development Libraries and Hea ii libdevel-symdu 2.03-3 Perl module for inspecting perl's symbol tab ii libentity-dev 1.0.1-7 XML-based GUI builder for GTK+ (core library ii libglib1.2-dev 1.2.10-9 Development files for GLib library ii libgtk1.2-dev 1.2.10-11 Development files for the GIMP Toolkit ii libstdc++2.10- 2.95.4-7 The GNU stdc++ library (development files) ii linux-kernel-h 2.5.999-test7- Linux Kernel Headers for development ii xlibs-dev 4.2.1-13 X Window System client library development f
here is were I'm stuck:
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c interlocked.c:299:3: #error You must implement the interlocked* functions for your CPU make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/usr/src/wine/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/usr/src/wine/libs' make: *** [libs] Error 2
Hmmm. Seems that either there is an official patch to apply, or that I won't be able to run wine on sun4u ... I'm have not enough skill in C at this time.
Kalou
On Tue, 12 Oct 2004, Olivier Kaloudoff wrote:
did you apply some sun4* patch before ./configure and make ? I'dbe glad to compile wine on my sun4u sun, too.
What patch exactly are you talking about? IMHO I haven't applied any patch here in my sun box.
I have the following headers installed on my machine, that might help you: (don't know if all are required by wine)
Thanks. IMHO I am missing only last two ones related to wine:
ii linux-kernel-h 2.5.999-test7- Linux Kernel Headers for development ii xlibs-dev 4.2.1-13 X Window System client library development f
I am afraid they won't help, but I will try installing them soon.
here is were I'm stuck:
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c interlocked.c:299:3: #error You must implement the interlocked* functions for your CPU make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/usr/src/wine/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/usr/src/wine/libs' make: *** [libs] Error 2
Hmmm. Seems that either there is an official patch to apply, or that I won't be able to run wine on sun4u ... I'm have not enough skill in C at this time.
Yes, Wine says it needs an implementation of interlocked* functions for your CPU. That is quite strange, as they seems to be implemented already:
s2@austechia:/usr/src/wine-20040914$ grep -iA10 sun libs/port/interlocked.c #elif defined(__sparc__) && defined(__sun__)
/* * As the earlier Sparc processors lack necessary atomic instructions, * I'm simply falling back to the library-provided _lwp_mutex routines * to ensure mutual exclusion in a way appropriate for the current * architecture. * * FIXME: If we have the compare-and-swap instruction (Sparc v9 and above) * we could use this to speed up the Interlocked operations ... */
Maybe some defines don't work? I am going to simplify this c-file out to find the inconsistence (during the next slice of my free time at this machine).
BTW, what kernel version are you using? Mine is 2.2.20.
Le mar 12/10/2004 à 09:23, Saulius Krasuckas a écrit : [snip]
Hmmm. Seems that either there is an official patch to apply, or that I won't be able to run wine on sun4u ... I'm have not enough skill in C at this time.
Yes, Wine says it needs an implementation of interlocked* functions for your CPU. That is quite strange, as they seems to be implemented already:
s2@austechia:/usr/src/wine-20040914$ grep -iA10 sun libs/port/interlocked.c #elif defined(__sparc__) && defined(__sun__)
__sun__ is defined when building for SunOS, not Linux. __sparc__ is the cpu architecture. Usually those functions are written in ASM as C can't provide access to the particular instructions needed to do the locking.
I just implemented those for __ALPHA__. If you don't know how/can't be bothered to do them in sparc assembly (which won't run on earlier machines as the following comment says), AND Debian don't provide the lwp libs, you can probably do the same using pthread primitives. I just hope that Wine's pthread replacement functions do not call the interlocked* functions, or it'll probably don't work correctly.
/*
- As the earlier Sparc processors lack necessary atomic instructions,
- I'm simply falling back to the library-provided _lwp_mutex routines
- to ensure mutual exclusion in a way appropriate for the current
- architecture.
- FIXME: If we have the compare-and-swap instruction (Sparc v9 and above)
we could use this to speed up the Interlocked operations ...*/
Maybe some defines don't work? I am going to simplify this c-file out to find the inconsistence (during the next slice of my free time at this machine).
As I said, __sun__ is the OS, __sparc__ the cpu. On Debian, __sun__ is not defined.
Vincent
On 12 Oct 2004, Vincent [ISO-8859-1] B�ron wrote:
Le mar 12/10/2004 � 09:23, Saulius Krasuckas a �crit :
Hmmm. Seems that either there is an official patch to apply, or that I won't be able to run wine on sun4u ... I'm have not enough skill in C at this time.
Yes, Wine says it needs an implementation of interlocked* functions for your CPU. That is quite strange, as they seems to be implemented already:
s2@austechia:/usr/src/wine-20040914$ grep -iA10 sun libs/port/interlocked.c #elif defined(__sparc__) && defined(__sun__)
__sun__ is defined when building for SunOS, not Linux. __sparc__ is the cpu architecture. Usually those functions are written in ASM as C can't provide access to the particular instructions needed to do the locking.
Oh, I've always used to thought that "sun" stands for another, more generic hardware too. Vincent, thanks for your welcome to the Sun-world. :-)
I just implemented those for __ALPHA__. If you don't know how/can't be bothered to do them in sparc assembly
Am I going to learn assembly for the sparc CPU? Cool.
(which won't run on earlier machines as the following comment says),
Vincent, do you mean different sparc CPUs are using different assembly instructions?
AND Debian don't provide the lwp libs,
I see there exist some Debian package on the net [1] called liblwp2, but apt-get on my box doesn't know about it. :-(
you can probably do the same using pthread primitives. I just hope that Wine's pthread replacement functions do not call the interlocked* functions, or it'll probably don't work correctly.
pthread primitives? Hm, reading what Wine src file should I start from?
- As the earlier Sparc processors lack necessary atomic instructions,
- I'm simply falling back to the library-provided _lwp_mutex routines
- to ensure mutual exclusion in a way appropriate for the current
- architecture.
- FIXME: If we have the compare-and-swap instruction (Sparc v9 and above)
we could use this to speed up the Interlocked operations ...
And out of curiousity: Olivier, what is your CPU? This is of mine:
austechia:~# cat /proc/cpuinfo cpu : Fujitsu MB86904 fpu : Lsi Logic/Meiko L64804 or compatible promlib : Version 3 Revision 2 prom : 2.24 type : sun4m ncpus probed : 1 ncpus active : 1 BogoMips : 109.77 MMU type : Fujitsu Swift invall : 0 invmm : 0 invrnge : 0 invpg : 0 contexts : 256
Le mer 13/10/2004 à 04:56, Saulius Krasuckas a écrit : [snip]
(which won't run on earlier machines as the following comment says),
Vincent, do you mean different sparc CPUs are using different assembly instructions?
It's the same thing as x86: the 386 introduced 32 bit mode and the instructions which go with it, the pentium MMX introduced the MMX instructions, etc.
AND Debian don't provide the lwp libs,
I see there exist some Debian package on the net [1] called liblwp2, but apt-get on my box doesn't know about it. :-(
you can probably do the same using pthread primitives. I just hope that Wine's pthread replacement functions do not call the interlocked* functions, or it'll probably don't work correctly.
pthread primitives? Hm, reading what Wine src file should I start from?
You can get a list of the pthread functions in loader/kthread.c. Just look at the name, some should have names similar to the _lwp variants.
Vincent
-
Olivier Kaloudoff -
Saulius Krasuckas -
Vincent Béron