On Mon, 10 Apr 2000, Patrik Stridvall wrote:
> > On Sun, 9 Apr 2000, Patrik Stridvall wrote:
[...]
> > You propose to modify the file contents of /usr/include?! I
> > don't think
> > that's a good idea, even if it's just to add symbolic links. I don't
> > think any Linux distribution would allow it either.
>
> 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.
> > 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.
Unless we move all the C headers out of wine/include and in a
subdirectory which might be a good idea.
[...]
> > 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 ;-).
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.
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.
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.
--
Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/
Avoid the Gates of Hell - use Linux.
