wine/port.h #include fixes

[François Gouget]

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
fgouget at codeweavers.com