Mingw64 and Cygwin: header and libs layout

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Jon,
Hi Chris,
Hi all others,


I'm working on building Cygwin with Mingw64 as the earliest stage in
moving Cygwin to 64 bit.  Obviously it doesn't make a lot of sense to
build 32 bit Cygwin with Mingw32/w32api and 64 bit Cygwin with Mingw64.
Therefore the w32api package will probably have to be replaced at one
point.  Please note that I'm not talking about the source repository
here, but about the state after installation.  The source repository
is an entirely different problem.

Anyway, I came across the problem that the Mingw64 header files are not
split in platform headers and mingw64 specific CRT headers.  The problem
is that the CRT headers collide with the headers of the same name from
newlib and Cygwin, so it's kind of bad to have them in the include
search path.

For the time being, I'm using the -idirafter flag to include the Mingw64
headers into the search path, but that's IMHO not a generic solution for
a (yet to create) Cygwin 64 bit GCC.

More or less the same problem comes up with the libs.  We have a couple
of clashes, for instance binmode.o, libm.a, libpthread.a.

Given that the Mingw64 project differs between CRT and platform headers
in the repository, and they are only merged into the same include
directory at install time, I was wondering if that couldn't be changed,
and perhaps even really soon to avoid problems later on.

Here's what I have in mind:

- Right now, the Mingw32 w32api headers are installed into two places:

  /usr/i686-pc-mingw32/sys-root/mingw/include for the Mingw32 cross GCC
  /usr/include/w32api for Cygwin's GCC.

  Analogous for /usr/lib/w32api

- Remove /usr/include/w32api and /usr/lib/w32api.

- The Mingw64 headers get split into platform headers and CRT headers,
  for instance into

  /usr/i686-w64-mingw32/sys-root/mingw/{include,lib} (CRT)
  /usr/i686-w64-mingw32/sys-root/w32api/{include,lib} (Platform)

  /usr/x86_64-w64-mingw32/sys-root/mingw/{include,lib} (CRT)
  /usr/x86_64-w64-mingw32/sys-root/w32api/{include,lib} (Platform)

- The Mingw64 cross-GCCs get spec files which take the splitting into
  account, just like the Cygwin GCC today has the /usr/include and the
  /usr/include/w32api paths in the include search path list by default
  (analogous for the libs).

- In Cygwin we create symlinks by default, for instance in the GCC
  package:

  ln -s /usr/i686-w64-mingw32/sys-root/w32api/include /usr/include/w32api
  ln -s /usr/x86_64-w64-mingw32/sys-root/w32api/include /usr/include/w64api
  ln -s /usr/i686-w64-mingw32/sys-root/w32api/lib /usr/lib/w32api
  ln -s /usr/x86_64-w64-mingw32/sys-root/w32api/lib /usr/lib64/w64api

Ok, that's it, basically.  The advantage is that at one point the w32api
directories could be replaced, but the Cygwin GCC would still work as
before.

Is that ok?  Or shall we solve the problem in a different way?  For
instance:

- Create new packages from the Mingw64 repo which install the platform
  headers and libs into /usr/{include,lib}/{w32api,w64api}, just like
  the w32api package today.

- Or, drop the /usr/{include,lib}/w32api (and /usr/{include,lib64}/w64api)
  symlinks or dirs entirely, and let the w32api replacement package
  install the platform headers and libs directly into /usr/include and
  /usr/lib{64}.
  
Or... any better idea?


Thanks,
Corinna

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