It's slowly coming around (Francois recent patches are key), but we still have some fairly serious issues.
Is this in? As of 10/17, it still blows up in NtCurrentTeb(). What does this function do? - is it trying to use a protected instruction? (in x86 instruction knowledge is pretty dated).
You've hit the first issue - being sure to use the GNU tool chain.
yup... want to try tackling that once I get the program to at least come up...
Doing a cvs update and trying again (after, of course, Alexandre commits Francois' recent patches) may bring you more joy.
a bold statement.. :)
I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.).
I take it that someone does have something that works on solx86?
-r
[snip]
I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.).
Right.
I take it that someone does have something that works on solx86?
I've played Solitaire several times on solx86! Now to get something useful to work...<g>
(AFAIK, the bulk of our working solx86 patches have been sent in by Francois; Alexandre can often get days behind in applying patches.)
Jer
Roger Fujii wrote:
It's slowly coming around (Francois recent patches are key), but we still have some fairly serious issues.
Is this in? As of 10/17, it still blows up in NtCurrentTeb(). What does this function do? - is it trying to use a protected instruction? (in x86 instruction knowledge is pretty dated).
You've hit the first issue - being sure to use the GNU tool chain.
yup... want to try tackling that once I get the program to at least come up...
You need to first make sure that you are using the GNU toolchain to build Wine. Otherwise Wine will not work. I believe that not even "./wine" will work. Do you have warnings about an unresolved main symbol when you link Wine's dlls? This is one of the symptoms. Another is when that strip does not understand "--strip-uneeded". Also note that just tweaking the PATH is not enough to switch from the Solaris toolchain to the GNU toolchain. That's because gcc is hard-coded to use '/usr/bin/xxx'. What we have done is to make these symlinks to the GNU toolchain (an alternative is to recompile gcc with the right path... but it takes more time). We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use.
Doing a cvs update and trying again (after, of course, Alexandre commits Francois' recent patches) may bring you more joy.
Alexandre has done a commit of my Solaris patches. The most useful one for you is the one that avoids printing NULL strings. But if you are using the wrong toolchain this will not help you.
I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.).
Yes, that works.
I take it that someone does have something that works on solx86?
Yes, a number of applications sort of work, including solitaire.
François Gouget wrote:
You need to first make sure that you are using the GNU toolchain to build Wine. Otherwise Wine will not work. I believe that not even "./wine" will work. Do you have warnings about an unresolved main symbol when you link Wine's dlls? This is one of the symptoms.
well, I had to add an -lc to the gcc -shared to resolve the libc labels on some of the libraries (winedbg and some others).
Another is when that strip does not understand "--strip-uneeded".
yup... it didn't...
We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use.
well, you could tell it with a -Bpath for gas/ld.
Alexandre has done a commit of my Solaris patches. The most useful one for you is the one that avoids printing NULL strings. But if you are using the wrong toolchain this will not help you.
it seems to be a little less cranky now. Think part of the problem was something wasn't being rebuilt correctly - did a make distclean and a reconfigure and it got me a little further.
I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.).
Yes, that works.
well, this turns out not to be the case, as wineserver is started from the installed prefix path.
Now, it starts up, then complains about not being able to stat fd0,cdrom; starts to build the font metrics (and complains about 16 fonts), then dies with the following stacktrace (if you believe gdb)
#0 0xdebe3eac in ?? () #1 0xdfae8285 in ?? () #2 0xdfaebe87 in ?? () #3 0xdfaf057f in ?? () #4 0xdfae31b9 in ?? () #5 0xdf9f5399 in RtlEnterCriticalSection (crit=0xdfabb108) at critsection.c:245 #6 0xdfa8a159 in _EnterSysLevel (lock=0xdfabb108) at syslevel.c:78 #7 0xdfa8a68a in RestoreThunkLock (mutex_count=0) at syslevel.c:198 #8 0xdfa28349 in OldYield16 () at task.c:686 #9 0xdfa28473 in DirectedYield16 (hTask=215) at task.c:716 #10 0xdfa2da96 in NE_CreateThread (pModule=0xdf661a80, cmdShow=1, cmdline=0xdf662064 "") at module.c:1004 #11 0xdfa2ddcd in NE_StartMain (name=0x804d660 "F:\playcvs\wine\sol.exe", file=20) at module.c:1114 #12 0x804c017 in wine_initial_task (inst=134520832, prev=0, cmdline=0xdf660e93 "", show=1) at main.c:37 #13 0x804b082 in __wine_exe_main () at wine.spec.c:71 #14 0xdfa85c52 in start_process () at process.c:390 #15 0xdfa89cc5 in SYSDEPS_DoCallOnStack (func=0xdfa85a0c <start_process>, arg=0x0) at sysdeps.c:172 #16 0xdfa89d9f in SYSDEPS_CallOnStack () at sysdeps.c:182 #17 0xdfa89e9a in SYSDEPS_SwitchToThreadStack (func=0xdfa85a0c <start_process>) at sysdeps.c:235 #18 0xdfa860c2 in PROCESS_InitWine (argc=2, argv=0x8047040, win16_exe_name=0x804d660 "F:\playcvs\wine\sol.exe", win16_exe_file=0x804d764) at process.c:518 #19 0x804c1b2 in main (argc=2, argv=0x804703c) at main.c:84
any chance you can mail me the wine binary and see if it bombs here too?
-r
Roger Fujii wrote:
François Gouget wrote:
You need to first make sure that you are using the GNU toolchain to build Wine. Otherwise Wine will not work. I believe that not even "./wine" will work. Do you have warnings about an unresolved main symbol when you link Wine's dlls? This is one of the symptoms.
well, I had to add an -lc to the gcc -shared to resolve the libc labels on some of the libraries (winedbg and some others).
I don't think you should not use '-shared' to compile the dlls. If you had trouble with the 'standard' '-Wl,-B,symbolic' then it's because you are using the wrong version of ld. It looks like instead of '-Wl,-B,symbolic' you could use '-symbolic'. This seems to automatically use the right switch for the ld that is being invoked. I wonder how this works and it probably requires testing. But you need the GNU ld anyway. As for '-lc' we had this problem too. I don't understand why we need to specify it explicitly. Maybe this is because we are not using the native ld. I would like to understand why we need to do so but it looks like we should have yet another configure check for this.
[...]
We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use.
well, you could tell it with a -Bpath for gas/ld.
It would be cleaner indeed. It looks like something that configure.in should check and set if necessary. Maybe it should even provide a configure option for that...
Alexandre has done a commit of my Solaris patches. The most useful one for you is the one that avoids printing NULL strings. But if you are using the wrong toolchain this will not help you.
it seems to be a little less cranky now. Think part of the problem was something wasn't being rebuilt correctly - did a make distclean and a reconfigure and it got me a little further.
I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.).
Yes, that works.
well, this turns out not to be the case, as wineserver is started from the installed prefix path.
I never install Wine! So Wine can never start wineserver from the installed prefix path and I never encountered this problem :-) Should Wine really try the installed prefix first? It seems to me that it should try it last instead. After all, if you change the path you would expect your change to have an effect, no? Plus checking the installed prefix first assumes that whichever version of wine is started (e.g. /home/fgouget/bin/wine) is the same as that of /usr/bin/wineserver! There's strictly no garantee of that. People normally set the PATH exactly for that purpose: to make sure that the right version of the wineserver will be started.
Now, it starts up, then complains about not being able to stat fd0,cdrom; starts to build the font metrics (and complains about 16 fonts), then dies with the following stacktrace (if you believe gdb)
[...backtrace snipped...]
Did not get that one.
any chance you can mail me the wine binary and see if it bombs here too?
I don't have it around here just now. I'll see if I can get a hold of it and send it to you.
François Gouget wrote:
well, I had to add an -lc to the gcc -shared to resolve the libc labels on some of the libraries (winedbg and some others).
I don't think you should not use '-shared' to compile the dlls.
err. double negatives... The choice of gcc -shared was done by configure.
If you had trouble with the 'standard' '-Wl,-B,symbolic' then it's because you are using the wrong version of ld.
actually, the solaris linker ate that. Now whether or not it does the same thing as gld is another matter.
It looks like instead of '-Wl,-B,symbolic' you could use '-symbolic'. This seems to automatically use the right switch for the ld that is being invoked. I wonder how this works and it probably requires testing.
presumably, it was figured by gcc configure...
But you need the GNU ld anyway.
just as a query, is there some documentation somewhere that explains why you need gld? gas is obvious, but it's not clear to me why gld makes a difference.
As for '-lc' we had this problem too. I don't understand why we need to specify it explicitly. Maybe this is because we are not using the native ld. I would like to understand why we need to do so but it looks like we should have yet another configure check for this.
funny you should mention this. Just got this from another maillist:
I get the following message from a distribution I created on Linux.
This is displayed when the configure script is run from the distribution directory.
*** Warning: Releases of GCC earlier than version 3.0 cannot reliably *** create self contained shared libraries on Solaris systems, without *** introducing a dependency on libgcc.a. Therefore, libtool is disabling *** -no-undefined support, which will at least allow you to build shared *** libraries. However, you may find that when you link such libraries *** into an application without using GCC, you have to manually add *** `gcc --print-libgcc-file-name` to the link command. We urge you to *** upgrade to a newer version of GCC. Another option is to rebuild your *** current GCC to use the GNU linker from GNU binutils 2.9.1 or newer.
We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use.
well, you could tell it with a -Bpath for gas/ld.
It would be cleaner indeed. It looks like something that configure.in should check and set if necessary. Maybe it should even provide a configure option for that...
I'm hoping to figure out how to make this use the native tools... (so I'm a masochist :) )
I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.).
Yes, that works.
well, this turns out not to be the case, as wineserver is started from the installed prefix path.
I never install Wine! So Wine can never start wineserver from the installed prefix path and I never encountered this problem :-)
yeah, yeah... now I know better....
any chance you can mail me the wine binary and see if it bombs here too?
I don't have it around here just now. I'll see if I can get a hold of it and send it to you.
cool. Thanks.
Roger Fujii wrote:
François Gouget wrote:
well, I had to add an -lc to the gcc -shared to resolve the libc labels on some of the libraries (winedbg and some others).
I don't think you should not use '-shared' to compile the dlls.
err. double negatives... The choice of gcc -shared was done by configure.
The dangers of rewriting a sentence. Still I find it strange that configure chose '-shared'. Ah, I see why: it's because now you are using the GNU binutils. Now that we get gcc to use the GNU binutils it uses '-shared' too.
If you had trouble with the 'standard' '-Wl,-B,symbolic' then it's because you are using the wrong version of ld.
actually, the solaris linker ate that. Now whether or not it does the same thing as gld is another matter.
I found that the Solaris linker gave a return code indicating success, but that in the make log, when linking Wine dlls, I would sometimes see errors about 'main' being an unresolved symbol. These went away when I switched to using '-symbolic' and also when we switched to using gld instead of ld.
[...]
But you need the GNU ld anyway.
just as a query, is there some documentation somewhere that explains why you need gld? gas is obvious, but it's not clear to me why gld makes a difference.
One thing we noticed was an alignment problem with the init section generated by winebuild. This caused a crash ow wine on startup and went away with gld. There may have been other issues.
As for '-lc' we had this problem too. I don't understand why we need to specify it explicitly. Maybe this is because we are not using the native ld. I would like to understand why we need to do so but it looks like we should have yet another configure check for this.
funny you should mention this. Just got this from another maillist:
I get the following message from a distribution I created on Linux.
This is displayed when the configure script is run from the distribution directory.
*** Warning: Releases of GCC earlier than version 3.0 cannot reliably *** create self contained shared libraries on Solaris systems, without *** introducing a dependency on libgcc.a. Therefore, libtool is disabling *** -no-undefined support, which will at least allow you to build shared *** libraries. However, you may find that when you link such libraries *** into an application without using GCC, you have to manually add *** `gcc --print-libgcc-file-name` to the link command. We urge you to *** upgrade to a newer version of GCC. Another option is to rebuild your *** current GCC to use the GNU linker from GNU binutils 2.9.1 or newer.
This only talks about libgcc, i.e. '-lgcc', not about libc, i.e. '-lc'. I did not notice any problem with libgcc. I am using gcc 2.95.3 btw.
We still have to investigate how to detect the Solaris toolchain and issue a big fat error message in the configure script. Also we should try to see if there is a way to tell gcc which toolchain to use.
well, you could tell it with a -Bpath for gas/ld.
It would be cleaner indeed. It looks like something that configure.in should check and set if necessary. Maybe it should even provide a configure option for that...
I'm hoping to figure out how to make this use the native tools... (so I'm a masochist :) )
This seems like something that would be best attempted once Wine works well with the GNU tools. Here is a short list of what needs to be done already: * enhance the configure script to better detect the binutils issues, and a few other problems (e.g. test -e, lex) * solve some process/thread id issues: Wine expects each thread to have a separate process id. This is necessary for proper handle inheritance * teach Wine how to send a signal to a specific LWP (hint, man -s 4 proc). This is for SuspendThread and needed by winedbg too. * get ptrace to work with LWPs. This is for winedbg. * fix all these _FILE_OFFSET_BITS warnings. I have the solution at hand. I just need some time to get back to it.
-
François Gouget -
Jeremy White -
Roger Fujii