wine/port.h #include fixes
rmf at lookhere.com
Thu Oct 18 20:29:13 CDT 2001
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
> *** 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.
Roger Fujii <rmf at lookhere.com>
Underemployed, and trying to keep it that way....
More information about the wine-devel