This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc4: next release (Dave Korn we need you)


On Jul  8 08:25, Charles Wilson wrote:
> On 7/8/2010 3:22 AM, Corinna Vinschen wrote:
> > On Jul  7 18:24, Christopher Faylor wrote:
> >> [...]
> >> Whether we use w32api in the cygwin tree or from somewhere else really
> >> doesn't matter as long as Cygwin builds.
> > 
> > That's why I'd like to know if Cygwin builds with w32api from the
> > mingw64 project.
> 
> Have you checked with Red Hat's lawyers concerning the use of mingw64's
> w32api to build their cygwin-based products?

That's something I'll doo as soon as we really intend to switch the
Cygwin build to mingw64's w32api.  Right now, what I get from all the
gory details, it's not that easy to keep mingw64's w32api headers and
libs apart from the mingw headers and libs anyway.

> > However, I won't object against having a version for the 64 bit gcc
> > hidden in the cross-compiler tree, if there's no way around it.
> > But *if* there's a way to keep just a single version, it should be
> > exploited.
> 
> I don't get this. There are three reasons to be concerned about multiple
> copies -- even if they are identical (which in this case they are not
> and can't be, esp. 64bit vs 32bit implibs).
>   1) disk space
>   2) things that should be identical (like headers for the
>      OS's API) out of sync, or keeping them deliberately different
>   3) end user confusion

You're missing number 4.  Cygwin and Mingw are targeting the same
underlying "real" target, which is Windows.  Both systems use different
approaches and both have their own set of libs and headers which only
make sense in their own environment.  But underneath they both run on
Windows.  For that reason my POV is that w32api is an intrinsic part of
the system and that's why it belongs into /usr/include and /usr/lib.
IMHO.

If there's no way around it, I don't mind if we have multiple w32api,
one for the system and one for each mingw cross compiler.  I don't
mind the disk space.  I don't know beforehand which solution will
result in more or less user confusion.  So just go ahead.

As for the path issue, I'd prefer to get a layout which closely
resembles the Fedora mingw filesystem layout as in
http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]