Re: Wine on Sparc

[Chuck Hall]

> Chuck Hall wrote:
> > Well it looks good.  I did get a few failures on the patching, but it
> > wnet
> > through 'make depend' without a problem.
> >
> > Now I run into the problem in kthread.c:
> > sed -e 's,@bindir@,/usr/local/bin,g' -e
> > 's,@dlldir@,/usr/local/lib/wine,g' -e 's,@PACKAGE_STRING@,Wine
> > 20050524,g' ./wine.man.in >wine.man || (rm -f wine.man && false)
> > gcc -c -I. -I. -I../include -I../include    -Wall -pipe
> > -fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2 -o kthread.o
> > kthread.c
> > kthread.c:322:3: #error You must implement wine_pthread_init_current_teb
> > for your platform
> > kthread.c:361:3: #error wine_pthread_get_current_teb not defined for
> > this
> > architecture
> > kthread.c: In function `wine_pthread_get_current_teb':
> > kthread.c:340: warning: 'ret' might be used uninitialized in this
> > function
> > *** Error code 1
> > make: Fatal error: Command failed for target `kthread.o'
> > Current working directory /tmp/wine-20050524/loader
> > *** Error code 1
> > The following command caused the error:
> > cd loader && make
> > make: Fatal error: Command failed for target `loader'
> >
> > Guess this is the next problem to work on :)
>
> Sounds like configure isn't detecting things properly.  It should be
> detecting '_lwp_create' and '_lwp_self', thus defining HAVE__LWP_CREATE
> and HAVE__LWP_SELF (in addition to HAVE_SYS_LWP_H).  Check your
> config.log to see what's going on.
>
> I did have problems with this stuff in older versions of wine, and I
> actually hacked the configure scripts to use wine-pthread instead of
> wine-kthread.  I don't recall the exact reasons, but it wine-kthread
> seems to be working fine for me now.

Started to go through this and found something intresting.  lwp.h does
exist and is found, so HAVE_SYS_LWP_H is defined.  The test for
_lwp_create fails.  Looking a bit deeper I found that the lwp.h for
Solaris 9 is different from the one in Solaris 10 (which is what I am
using).  Based on this and something I read awhile ago, I belive that Sun
is attempting to phase out the lwp stuff on Solaris.

It looks like a workaround will need to be created for _lwp_create.  I
will look into this and see what is the "official" way to write the code
now, if any.  Also a workaround will need to be made for all other _lwp_*
calls that no longer exist.

Have Fun!
Chuck Hall

Wine on Sparc

[Eric Frias]

Chuck Hall wrote:
> Started to go through this and found something intresting.  lwp.h does
> exist and is found, so HAVE_SYS_LWP_H is defined.  The test for
> _lwp_create fails.  Looking a bit deeper I found that the lwp.h for
> Solaris 9 is different from the one in Solaris 10 (which is what I am
> using).  Based on this and something I read awhile ago, I belive that Sun
> is attempting to phase out the lwp stuff on Solaris.
>
> It looks like a workaround will need to be created for _lwp_create.  I
> will look into this and see what is the "official" way to write the code
> now, if any.  Also a workaround will need to be made for all other _lwp_*
> calls that no longer exist.

Ah.. I'm using Solaris 8 so the LWP stuff just worked.  I guess the 
correct thing to do here is just use the pthread model.  It's probably 
safer to make pthread the default model on Solaris.  I had it working 
well with my 6-month-old version of wine, so it shouldn't be too 
difficult to get it working with the current one.

You'll need to add a section to configure.ac to tell it to build 
wine-pthread instead of wine-kthread:

@@ -1078,6 +1089,10 @@
      esac
      AC_SUBST(MAIN_BINARY,"wine-glibc")
      ;;
+  solaris*)
+    AC_SUBST(WINE_BINARIES,"wine-pthread")
+    AC_SUBST(MAIN_BINARY,"wine-pthread")
+    ;;
    darwin*)
      AC_SUBST(WINE_BINARIES,"wine-pthread")
      AC_SUBST(MAIN_BINARY,"wine-pthread")

and probably get rid of the checks for _lwp_create & _lwp_self:

@@ -1116,11 +1131,10 @@

dnl **** Check for functions ****
+dnl EMF: removed _lwp_create and _lwp_self

AC_FUNC_ALLOCA()
  AC_CHECK_FUNCS(\
-       _lwp_create \
-       _lwp_self \
         _pclose \
         _popen \
         _snprintf \

I'll dig around next week and see if I can figure out why wine-pthread 
seems to crash on my system.  The stack trace looks strangely familiar...

Eric

Wine on Sparc

[Chuck Hall]

> Chuck Hall wrote:
> > Started to go through this and found something intresting.  lwp.h does
> > exist and is found, so HAVE_SYS_LWP_H is defined.  The test for
> > _lwp_create fails.  Looking a bit deeper I found that the lwp.h for
> > Solaris 9 is different from the one in Solaris 10 (which is what I am
> > using).  Based on this and something I read awhile ago, I belive that
> > Sun
> > is attempting to phase out the lwp stuff on Solaris.
> >
> > It looks like a workaround will need to be created for _lwp_create.  I
> > will look into this and see what is the "official" way to write the code
> > now, if any.  Also a workaround will need to be made for all other
> > _lwp_*
> > calls that no longer exist.
>
> Ah.. I'm using Solaris 8 so the LWP stuff just worked.  I guess the
> correct thing to do here is just use the pthread model.  It's probably
> safer to make pthread the default model on Solaris.  I had it working
> well with my 6-month-old version of wine, so it shouldn't be too
> difficult to get it working with the current one.
>
> You'll need to add a section to configure.ac to tell it to build
> wine-pthread instead of wine-kthread:
>
> @@ -1078,6 +1089,10 @@
>       esac
>       AC_SUBST(MAIN_BINARY,"wine-glibc")
>       ;;
> - solaris*)
> - AC_SUBST(WINE_BINARIES,"wine-pthread")
> - AC_SUBST(MAIN_BINARY,"wine-pthread")
> - ;;
> darwin*)
>  AC_SUBST(WINE_BINARIES,"wine-pthread")
>  AC_SUBST(MAIN_BINARY,"wine-pthread")
>
> and probably get rid of the checks for _lwp_create & _lwp_self:
>
> @@ -1116,11 +1131,10 @@
>
> dnl **** Check for functions ****
> +dnl EMF: removed _lwp_create and _lwp_self
>
> AC_FUNC_ALLOCA()
>   AC_CHECK_FUNCS(\
> -
>   _lwp_create \
> -
>   _lwp_self \
>    _pclose \
>    _popen \
>    _snprintf \
>
> I'll dig around next week and see if I can figure out why wine-pthread
> seems to crash on my system.  The stack trace looks strangely familiar...

Well the patches worked, I did need to change the first one slightly to
make it work.

Now I'm running into the problem of OpenGL, but I think this is solveable
by pointing to Mesa instead of the native GL system.  Not that I really
need OpenGL through a terminal window...

Have Fun!
Chuck Hall

Wine on Sparc

[Robert Lunnon]

On Saturday 28 May 2005 06:19, Chuck Hall wrote:
> > Chuck Hall wrote:
> > > Well it looks good.  I did get a few failures on the patching, but it
> > > wnet
> > > through 'make depend' without a problem.
> > >
> > > Now I run into the problem in kthread.c:
> > > sed -e 's,@bindir@,/usr/local/bin,g' -e
> > > 's,@dlldir@,/usr/local/lib/wine,g' -e 's,@PACKAGE_STRING@,Wine
> > > 20050524,g' ./wine.man.in >wine.man || (rm -f wine.man && false)
> > > gcc -c -I. -I. -I../include -I../include    -Wall -pipe
> > > -fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2 -o kthread.o
> > > kthread.c
> > > kthread.c:322:3: #error You must implement wine_pthread_init_current_teb
> > > for your platform
> > > kthread.c:361:3: #error wine_pthread_get_current_teb not defined for
> > > this
> > > architecture
> > > kthread.c: In function `wine_pthread_get_current_teb':
> > > kthread.c:340: warning: 'ret' might be used uninitialized in this
> > > function
> > > *** Error code 1
> > > make: Fatal error: Command failed for target `kthread.o'
> > > Current working directory /tmp/wine-20050524/loader
> > > *** Error code 1
> > > The following command caused the error:
> > > cd loader && make
> > > make: Fatal error: Command failed for target `loader'
> > >
> > > Guess this is the next problem to work on :)
> >
> > Sounds like configure isn't detecting things properly.  It should be
> > detecting '_lwp_create' and '_lwp_self', thus defining HAVE__LWP_CREATE
> > and HAVE__LWP_SELF (in addition to HAVE_SYS_LWP_H).  Check your
> > config.log to see what's going on.
> >
> > I did have problems with this stuff in older versions of wine, and I
> > actually hacked the configure scripts to use wine-pthread instead of
> > wine-kthread.  I don't recall the exact reasons, but it wine-kthread
> > seems to be working fine for me now.
>
> Started to go through this and found something intresting.  lwp.h does
> exist and is found, so HAVE_SYS_LWP_H is defined.  The test for
> _lwp_create fails.  Looking a bit deeper I found that the lwp.h for
> Solaris 9 is different from the one in Solaris 10 (which is what I am
> using).  Based on this and something I read awhile ago, I belive that Sun
> is attempting to phase out the lwp stuff on Solaris.
>
> It looks like a workaround will need to be created for _lwp_create.  I
> will look into this and see what is the "official" way to write the code
> now, if any.  Also a workaround will need to be made for all other _lwp_*
> calls that no longer exist.
>
> Have Fun!
> Chuck Hall

Chuck, didn't I send you the full kit of changes for Solaris ? You can usually 
find them on members.optushome.com.au/bobl, get the Solaris 10 patch-kit, 
though they are  little dated there at the moment (Mostly because wine had a 
regression last weekend that prevents it working properly, and I don't 
publish non-working binaries)

Anyway, you are re-inventing the wheel here, you will need the attached patch 
which will allow you to use either sysv native threads or lwp's if you like. 
LWPs are not supported post Solaris 9, but there are other problems to 
overcome, particularly ptrace and the debugger. This implementation is pretty 
well tested, event if not ready for primetime (Ugly debugging code is still 
in there).

Bob