> On Mon, 10 Apr 2000, Patrik Stridvall wrote:
> > Huh? In my Debian Linux /usr/include directory is a large amount
> > of various header files for different packages.
>
> You have a point. Still I would rather put them in a separate
> directory (like X11).
> In any case this decision belongs to the distribution, not to
> Wine so it should be irrelevant to our discussion.
True.
> > > Just let the people compiling Windows application put a
> > > '-I/usr/include/windows' in their include path. They'll have
> > > to write
> > > makefiles to compile with Winelib anyway.
> >
> > Of course but why make it more difficult to use when it has to be.
>
> Because it makes no difference to them since they'll will most
> likely have to do so anyway in order to get the right headers
> for the C
> library.
The problem is that /usr/include/windows will contain files like
stdlib.h, stdio.h and friend you will have to be careful so the
right include files is used for each mode. It is mainly Unix mode
that "needs" the "links" in /usr/include to help the user avoid
wrong includes.
> Unless we move all the C headers out of wine/include and in a
> subdirectory which might be a good idea.
It is not certain that it is nessary to have the same layout in the Wine
tree as after installation. It might be nessary though, I'm not sure.
> [...]
> > > Yes but you cannot based yourself on the compiler to determine
> > > whether you should include libc5 or glibc (2.0, 2.1, ...) (or
> > > can you?).
> > > I think it's better to control this at the include path level
> > > (including
> > > using symbolic links if necessary)
> >
> > Yes you are right, but that is beyond the scope of Wine.
> > It is the package maintainers problem and as I said
> > it is only a problem if non-GNU C compilers are used.
>
>
> I'm surprised that you should say that ;-).
There is nothing that say that Mixed mode needs to be supported on
with non-GNU C compiler. They still have Windows mode and Unix
mode they can use. That said it can be support using your header
link trick, I believe.
> I think that Winelib is where using a non GNU C compiler makes
> the most sense. I know of a C++ application which is linked
> to a closed
> source library on Sparc Solaris. Just compiling a 'hello world'
> application with g++ and linking it with the closed source library
> crashes the 'hello world' application on startup.
I'm not very suprised. That is one of the reason I want WineLib to
be compilable with a C++ compiler to support platforms like that.
Of course it is not certain it is nessary to compile WineLib with
such a compiler but it might and it is not absolutely certain that
a corresponding C compiler might exist.
> So I could very wrell imagine a case where an application tries
> to port an application to Winelib and tries to link with a
> closed source
> library from the same vendor they use for Windows. But then they might
> be blocked if they cannot use a compiler that's compatible with that
> closed source library.
> I know that anyone not using gcc will encounter other problems:
> calling convention but on Sparc Solaris it does not really matter, C
> extensions but it just means they'll have to modify their
> code a bit, or
> use a tool that does most of the work automatically. But
> still, I think
> it would be better to try not to make the situation even harder by not
> using gcc specific features when we can find alternatives.
So we don't support Mixed mode on non-GNU C.
Beside Alexandre doesn't seem thrilled at
supporting Mixed mode at all...
> I did not get time to look at your patches. But I'm really
> interested in having a look at them so I'll definitely try to do so
> soon.
The attached files are just a partial implementation of the Windows
stdio.h, stdlib.h and friends. Not much to see. I attached them to
show that some of the work is done.
