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.