I have posted my question for compiling Wine in solaris x86 for 2 weeks, seems no anybody even has a bit interest.
Do you guys hate solaris? :)
I checked almost all the documents and faq, except it mentioned wine works with Solaris, there almost have no other info for it at all.
Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)
On Thu, Jul 26, 2001 at 10:04:03AM -0700, EriK W wrote:
I have posted my question for compiling Wine in solaris x86 for 2 weeks, seems no anybody even has a bit interest.
Do you guys hate solaris? :)
No. We just do not have it, so we can't use it.
I checked almost all the documents and faq, except it mentioned wine works with Solaris, there almost have no other info for it at all.
Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)
Try WINE first, fix/report the errors?
Ciao, Marcus
On Thu, 26 Jul 2001, EriK W wrote:
I have posted my question for compiling Wine in solaris x86 for 2 weeks, seems no anybody even has a bit interest.
The only message I see from you is the one you posted on wine-devel the 24th, two *days* ago.
Do you guys hate solaris? :)
I don't think so. But few Wine developpers use Solaris which makes it harder for them to help you. I myself
[...]
Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)
No, certainly not. We need you if Wine is going to keep supporting Solaris :-)
So from you previous email:
[...]
/usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h 1.2 00/07/05 SMI
This one does not really matter.
gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec ./ntdll.spec ld.so.1: ../../tools/winebuild/winebuild: fatal: /usr/local/lib/libwine_unicode.so: open failed: No such file or directory
winebuild is linked with 'libwine_unicode.so' which should have been compiled previously and should be in 'wine/unicode'. So the LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot execute because that library cannot be found. So: * does unicode/libwine_unicode.so exist? * in the compilation process you should see Wine go into the unicode subdirectory and compile stuff there. Do you indeed see something like that? * try to start winebuild manually. When in Wine's root directory type "./tools/winebuild/winebuild'. Does it work? If not try to tweak LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than relative ones?
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
The only message I see from you is the one you posted on wine-devel the 24th, two *days* ago.
Actually, before this I posted it to comp.emulators-windows.wine couple times without even a reply. :)
And I think I am not the only one encountered this problem, I found exactly same report http://wine.codeweavers.com/cgi-bin/fom?_highlightWords=usr%20local%20lib%20 libwine%20unicode%20so%20open%20failed&file=424 with no any follow up yet, Though I don't know when he reported this problem.
Anyway, thanks for your work and replies!
Do you guys hate solaris? :)
I don't think so. But few Wine developpers use Solaris which makes it harder for them to help you. I myself
[...]
Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)
No, certainly not. We need you if Wine is going to keep supporting Solaris :-)
So from you previous email:
[...]
/usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma:
"@(#)Xutil.h
1.2 00/07/05 SMI
This one does not really matter.
gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o
ts_xf86dga.o
ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o
libwine_tsx11.so.1.0
rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o
ntdll.spec.c -spec
./ntdll.spec ld.so.1: ../../tools/winebuild/winebuild: fatal: /usr/local/lib/libwine_unicode.so: open failed: No such file or
directory
winebuild is linked with 'libwine_unicode.so' which should have been compiled previously and should be in 'wine/unicode'. So the LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot execute because that library cannot be found. So:
- does unicode/libwine_unicode.so exist?
- in the compilation process you should see Wine go into the unicode
subdirectory and compile stuff there. Do you indeed see something like that?
- try to start winebuild manually. When in Wine's root directory type
"./tools/winebuild/winebuild'. Does it work? If not try to tweak LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than relative ones?
Doesn't work, I guess there is a problem in Makefile. Eventually I copied the file to /usr/local/lib . But then I run into another problem.
gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o msc.o msc.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o registers.o registers.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o source.o source.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o stabs.c stabs.c:1271: warning: `struct r_debug' declared inside parameter list stabs.c:1271: warning: its scope is only this definition or declaration, which is probably not what you want. stabs.c: In function `DEBUG_WalkList': stabs.c:1274: storage size of `lm' isn't known stabs.c:1284: dereferencing pointer to incomplete type stabs.c:1274: warning: unused variable `lm' stabs.c:1273: warning: `lm_addr' might be used uninitialized in this function stabs.c: In function `DEBUG_RescanElf': stabs.c:1302: storage size of `dbg_hdr' isn't known stabs.c:1309: `RT_CONSISTENT' undeclared (first use in this function) stabs.c:1309: (Each undeclared identifier is reported only once stabs.c:1309: for each function it appears in.) stabs.c:1313: `RT_ADD' undeclared (first use in this function) stabs.c:1315: `RT_DELETE' undeclared (first use in this function) stabs.c:1310: warning: unreachable code at beginning of switch statement stabs.c:1302: warning: unused variable `dbg_hdr' stabs.c: In function `DEBUG_ReadExecutableDbgInfo': stabs.c:1324: `Elf32_Dyn' undeclared (first use in this function) stabs.c:1324: parse error before `dyn' stabs.c:1325: storage size of `dbg_hdr' isn't known stabs.c:1336: `dyn' undeclared (first use in this function) stabs.c:1339: `DT_DEBUG' undeclared (first use in this function) stabs.c:1339: `DT_NULL' undeclared (first use in this function) stabs.c:1325: warning: unused variable `dbg_hdr' make[1]: *** [stabs.o] Error 1 make[1]: Leaving directory `/export/home/system/wine-20010629/debugger' make: *** [debugger/winedbg] Error 2
Compilation failed, aborting install.
Any idea?
--
On Thu, 26 Jul 2001, EriK W wrote:
The only message I see from you is the one you posted on wine-devel the 24th, two *days* ago.
Actually, before this I posted it to comp.emulators-windows.wine couple times without even a reply. :)
Yes, I suspected as much. I sometimes read cemw but my ISPs news server is real bad. Not as bad as the news feed of Corel who's hosting wine-users. It's been over a month now that the link between wine-users and cemw has been severed :-(
[...]
winebuild is linked with 'libwine_unicode.so' which should have been compiled previously and should be in 'wine/unicode'. So the LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot execute because that library cannot be found. So:
- does unicode/libwine_unicode.so exist?
- in the compilation process you should see Wine go into the unicode
subdirectory and compile stuff there. Do you indeed see something like that?
- try to start winebuild manually. When in Wine's root directory type
"./tools/winebuild/winebuild'. Does it work? If not try to tweak LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than relative ones?
Doesn't work, I guess there is a problem in Makefile.
What does not work? Do you have unicode/libwine_unicode.so or not? Does the following command run or does it say it cannot find libwine_unicode.so? LD_LIBRARY_PATH="unicode:$LD_LIBRARY_PATH" ./tools/winebuild/winebuild
Btw, what is your default shell?
[...]
gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o stabs.c stabs.c:1271: warning: `struct r_debug' declared inside parameter list stabs.c:1271: warning: its scope is only this definition or declaration, which is probably not what you want.
On my system r_debug is defined in '/usr/include/link.h'. According to dpkg this is part of libc6-dev. So the problem is that the Solaris C library does not define it. The link.h header says:
Data structure for communication from the run-time dynamic linker for loaded ELF shared objects.
The easy way out is to say that winedbg is not essential to get Wine working. So you could decide not to compile it at all. A better approach would be to either provide this r_debug structure somehow if it is relevant on Solaris, or remove all the related stuff on Solaris. I'm not a winedbg expert so I've reached my limit here. Maybe Eric Pouech could advise you better.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
What does not work? Do you have unicode/libwine_unicode.so or not? Does the following command run or does it say it cannot find libwine_unicode.so?
I does have the libwine_unicode.so but it just don't go to ~unicode directory to search for it, it always report " can't find it in /usr/local/lib" I don't know why, I am using bash, so I just simply copied libwine_unicode.so over to make it happy.
[...]
gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou
ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o
On my system r_debug is defined in '/usr/include/link.h'. According to dpkg this is part of libc6-dev. So the problem is that the Solaris C library does not define it. The link.h header says:
Data structure for communication from the run-time dynamic linker for loaded ELF shared objects.
The easy way out is to say that winedbg is not essential to get Wine working. So you could decide not to compile it at all.
take it out? Can I do that by commenting " LIBPROGRAMS = \ debugger/winedbg" ?
A better approach would be to either provide this r_debug structure somehow if it is relevant on Solaris, or remove all the related stuff on Solaris. I'm not a winedbg expert so I've reached my limit here. Maybe Eric Pouech could advise you better.
OK, then I think I probably should be a quite beaver to sit and wait Eric Pouech to figure it out. :)
Millions thanks, Francois!!
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
On Thu, 26 Jul 2001, EriK W wrote:
What does not work? Do you have unicode/libwine_unicode.so or not? Does the following command run or does it say it cannot find libwine_unicode.so?
I does have the libwine_unicode.so but it just don't go to ~unicode directory to search for it, it always report " can't find it in /usr/local/lib" I don't know why, I am using bash, so I just simply copied libwine_unicode.so over to make it happy.
I was wondering if it was the shell not exporting the environment variable or something. Since you're using bash it should be all fine. So you have to figure out why setting LD_LIBRARY_PATH does not work. It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I really don't see why it would not work on Solaris x86. Plus LD_LIBRARY_PATH is such an important thing that it would be very surprising if it really did not work and nothing else was broken in your system.
Did you try specifying an absolute path like: LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode ./tools/winebuild/winebuild
What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty?
[...]
take it out? Can I do that by commenting " LIBPROGRAMS = \ debugger/winedbg" ?
The following patch should do that nicely:
--- cut here --- Index: Makefile.in =================================================================== RCS file: /home/wine/wine/debugger/Makefile.in,v retrieving revision 1.24 diff -u -r1.24 Makefile.in --- Makefile.in 2000/12/29 05:38:00 1.24 +++ Makefile.in 2001/07/27 01:39:15 @@ -3,7 +3,7 @@ TOPOBJDIR = .. SRCDIR = @srcdir@ VPATH = @srcdir@ -MODULE = winedbg +MODULE = #winedbg
C_SRCS = \ break.c \ --- Makefile.orig Thu Jul 26 19:03:36 2001 +++ Makefile Thu Jul 26 19:00:53 2001 @@ -3,7 +3,7 @@ TOPSRCDIR = .. TOPOBJDIR = .. SRCDIR = . -MODULE = winedbg +MODULE = #winedbg
C_SRCS = \ break.c \ --- cut here ---
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !
Now I finally made a wine , :) But I can't get any program to excute so far, mostly It is like
bash-2.03# wine --winver win95 sol.exe err:seh:UnhandledExceptionFilter Couldn't start debugger (debugger/winedbg 134639312 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger
or
bash-2.03# wine --winver win98 icq2000b.exe err:win32:do_relocations Standard load address for a Win32 program not available - patched kernel ? err:win32:do_relocations FATAL: Need to relocate F:\export\home\ericw\system\icq2000b.exe, but no relocation records present (stripped during link). Try to run that file directly ! wine: can't exec 'icq2000b.exe': error=21
This wine seems taste not good, :)
Francois Gouget wrote:
On Thu, 26 Jul 2001, EriK W wrote:
What does not work? Do you have unicode/libwine_unicode.so or not? Does the following command run or does it say it cannot find libwine_unicode.so?
I does have the libwine_unicode.so but it just don't go to ~unicode directory to search for it, it always report " can't find it in /usr/local/lib" I don't know why, I am using bash, so I just simply copied libwine_unicode.so over to make it happy.
I was wondering if it was the shell not exporting the environment variable or something. Since you're using bash it should be all fine. So you have to figure out why setting LD_LIBRARY_PATH does not work. It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I really don't see why it would not work on Solaris x86. Plus LD_LIBRARY_PATH is such an important thing that it would be very surprising if it really did not work and nothing else was broken in your system.
Did you try specifying an absolute path like: LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode ./tools/winebuild/winebuild
What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty?
[...]
take it out? Can I do that by commenting " LIBPROGRAMS = \ debugger/winedbg" ?
The following patch should do that nicely:
--- cut here --- Index: Makefile.in =================================================================== RCS file: /home/wine/wine/debugger/Makefile.in,v retrieving revision 1.24 diff -u -r1.24 Makefile.in --- Makefile.in 2000/12/29 05:38:00 1.24 +++ Makefile.in 2001/07/27 01:39:15 @@ -3,7 +3,7 @@ TOPOBJDIR = .. SRCDIR = @srcdir@ VPATH = @srcdir@ -MODULE = winedbg +MODULE = #winedbg
C_SRCS = \ break.c \ --- Makefile.orig Thu Jul 26 19:03:36 2001 +++ Makefile Thu Jul 26 19:00:53 2001 @@ -3,7 +3,7 @@ TOPSRCDIR = .. TOPOBJDIR = .. SRCDIR = . -MODULE = winedbg +MODULE = #winedbg
C_SRCS = \ break.c \ --- cut here ---
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !
gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o stabs.c stabs.c:1271: warning: `struct r_debug' declared inside parameter list stabs.c:1271: warning: its scope is only this definition or declaration, which is probably not what you want. stabs.c: In function `DEBUG_WalkList': stabs.c:1274: storage size of `lm' isn't known stabs.c:1284: dereferencing pointer to incomplete type stabs.c:1274: warning: unused variable `lm' stabs.c:1273: warning: `lm_addr' might be used uninitialized in this function stabs.c: In function `DEBUG_RescanElf': stabs.c:1302: storage size of `dbg_hdr' isn't known stabs.c:1309: `RT_CONSISTENT' undeclared (first use in this function) stabs.c:1309: (Each undeclared identifier is reported only once stabs.c:1309: for each function it appears in.) stabs.c:1313: `RT_ADD' undeclared (first use in this function) stabs.c:1315: `RT_DELETE' undeclared (first use in this function) stabs.c:1310: warning: unreachable code at beginning of switch statement stabs.c:1302: warning: unused variable `dbg_hdr' stabs.c: In function `DEBUG_ReadExecutableDbgInfo': stabs.c:1324: `Elf32_Dyn' undeclared (first use in this function) stabs.c:1324: parse error before `dyn' stabs.c:1325: storage size of `dbg_hdr' isn't known stabs.c:1336: `dyn' undeclared (first use in this function) stabs.c:1339: `DT_DEBUG' undeclared (first use in this function) stabs.c:1339: `DT_NULL' undeclared (first use in this function) stabs.c:1325: warning: unused variable `dbg_hdr' make[1]: *** [stabs.o] Error 1 make[1]: Leaving directory `/export/home/system/wine-20010629/debugger' make: *** [debugger/winedbg] Error 2
Compilation failed, aborting install.
Any idea?
this is due to the differences in ELF symbol loading between Linux/BSD and Solaris. This has to be fixed, some day. One simple fix would be to turn off manually the ELF definition at the top of the debugger/stabs.c file. If you're still around in the next day, I may send you some fixes to test if they work on Solaris
(this is the part to be removed)
#if defined(__svr4__) || defined(__sun) #define __ELF__ #endif
A+
-
eric pouech -
EriK W -
Francois Gouget -
Marcus Meissner -
Super-User