wine/port.h #include fixes

[Roger Fujii]

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 <rmf at lookhere.com>
Underemployed, and trying to keep it that way....