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 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
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
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
-
Chuck Hall -
Eric Frias -
Robert Lunnon