wine/port.h #include fixes

[François Gouget]

Roger Fujii wrote:
> 
> François Gouget wrote:
> 
> >    You need to first make sure that you are using the GNU toolchain to
> > build Wine. Otherwise Wine will not work. I believe that not even
> > "./wine" will work. Do you have warnings about an unresolved main symbol
> > when you link Wine's dlls? This is one of the symptoms.
> 
> 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. If
you had trouble with the 'standard' '-Wl,-B,symbolic' then it's because
you are using the wrong version of ld.
   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.
   But you need the GNU ld anyway.
   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.


[...]
> >    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...


> >    Alexandre has done a commit of my Solaris patches. The most useful
> > one for you is the one that avoids printing NULL strings. But if you are
> > using the wrong toolchain this will not help you.
> 
> it seems to be a little less cranky now.  Think part of the problem was
> something wasn't being rebuilt correctly - did a make distclean and
> a reconfigure and it got me a little further.
> 
> > > 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 :-)
   Should Wine really try the installed prefix first? It seems to me
that it should try it last instead. After all, if you change the path
you would expect your change to have an effect, no? Plus checking the
installed prefix first assumes that whichever version of wine is started
(e.g. /home/fgouget/bin/wine) is the same as that of
/usr/bin/wineserver! There's strictly no garantee of that. People
normally set the PATH exactly for that purpose: to make sure that the
right version of the wineserver will be started.


> Now, it starts up, then complains about not being able to stat fd0,cdrom;
> starts to build the font metrics (and complains about 16 fonts), then dies
> with the following stacktrace (if you believe gdb)
[...backtrace snipped...]

   Did not get that one.


> 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.


-- 
François Gouget
fgouget at codeweavers.com