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.