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