Mingw64 and Cygwin: header and libs layout

Mingw64 and Cygwin: header and libs layout

[Corinna Vinschen]

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

Re: Mingw64 and Cygwin: header and libs layout

[Kai Tietz]

Hi Corinna,

I suggest the approach to install for cygwin the platform-headers to a
shared place.  I suggest that mingw-w64 adds to configure for headers
and crt an option, which installs platform-headers/libraries to
'/usr/shared/psdk_windows' location.  Means under this path are the
folders lib/lib64/include containing only the platform-parts.
For the cygwin-based mingw-w64 cross-compiler we need to add here by
spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
should be a special configuration option for gcc (and binutils), which
adds the required parts to spec-files.

The CRT libraries and headers should stay IMHO in private places for
toolchain.  There is no need to put them under different locations or
to have them at shared-locations AFAICS., as cygwin-toolchain won't
provide this '-mno-cygwin' approach.  So toolchains are regarding
their CRT-headers isolated.

Regards,
Kai

Re: Mingw64 and Cygwin: header and libs layout

[Corinna Vinschen]

Hi Kai,

On Mar 13 14:25, Kai Tietz wrote:
> Hi Corinna,
> 
> I suggest the approach to install for cygwin the platform-headers to a
> shared place.  I suggest that mingw-w64 adds to configure for headers
> and crt an option, which installs platform-headers/libraries to
> '/usr/shared/psdk_windows' location.  Means under this path are the
> folders lib/lib64/include containing only the platform-parts.

That sounds like an excellent idea to me!

> For the cygwin-based mingw-w64 cross-compiler we need to add here by
> spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
> should be a special configuration option for gcc (and binutils), which
> adds the required parts to spec-files.

IMHO we should keep the "w32api" scheme.  The reason is that this
requires no changes at all to the gcc specs file.  Rather, the Cygwin
gcc package would simply create matching symlinks:

  ln -s /usr/share/windows_psdk/include /usr/include/w32api
  ln -s /usr/share/windows_psdk/lib     /usr/lib/w32api
  ln -s /usr/share/windows_psdk/lib64   /usr/lib64/w32api

> The CRT libraries and headers should stay IMHO in private places for
> toolchain.  There is no need to put them under different locations or
> to have them at shared-locations AFAICS., as cygwin-toolchain won't
> provide this '-mno-cygwin' approach.  So toolchains are regarding
> their CRT-headers isolated.

Absolutely.


Thanks,
Corinna

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

Re: Mingw64 and Cygwin: header and libs layout

[Christopher Faylor]

On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
>Hi Kai,
>
>On Mar 13 14:25, Kai Tietz wrote:
>> Hi Corinna,
>> 
>> I suggest the approach to install for cygwin the platform-headers to a
>> shared place.  I suggest that mingw-w64 adds to configure for headers
>> and crt an option, which installs platform-headers/libraries to
>> '/usr/shared/psdk_windows' location.  Means under this path are the
>> folders lib/lib64/include containing only the platform-parts.
>
>That sounds like an excellent idea to me!
>
>> For the cygwin-based mingw-w64 cross-compiler we need to add here by
>> spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
>> should be a special configuration option for gcc (and binutils), which
>> adds the required parts to spec-files.
>
>IMHO we should keep the "w32api" scheme.  The reason is that this
>requires no changes at all to the gcc specs file.  Rather, the Cygwin
>gcc package would simply create matching symlinks:
>
>  ln -s /usr/share/windows_psdk/include /usr/include/w32api
>  ln -s /usr/share/windows_psdk/lib     /usr/lib/w32api
>  ln -s /usr/share/windows_psdk/lib64   /usr/lib64/w32api

I think it's pretty unusual to install libraries and headers in
/usr/share, particularly in the case of libraries.  gcc/linux has
conventions for this type of thing.  I broke them when I installed
headers and libraries in /usr/include/w32api.  I don't think we should
stray further by putting things in /usr/share.

Could Dave Korn weigh in on this?

cgf

Re: Mingw64 and Cygwin: header and libs layout

[Corinna Vinschen]

On Mar 13 09:51, Christopher Faylor wrote:
> On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
> >Hi Kai,
> >
> >On Mar 13 14:25, Kai Tietz wrote:
> >> Hi Corinna,
> >> 
> >> I suggest the approach to install for cygwin the platform-headers to a
> >> shared place.  I suggest that mingw-w64 adds to configure for headers
> >> and crt an option, which installs platform-headers/libraries to
> >> '/usr/shared/psdk_windows' location.  Means under this path are the
> >> folders lib/lib64/include containing only the platform-parts.
> >
> >That sounds like an excellent idea to me!
> >
> >> For the cygwin-based mingw-w64 cross-compiler we need to add here by
> >> spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
> >> should be a special configuration option for gcc (and binutils), which
> >> adds the required parts to spec-files.
> >
> >IMHO we should keep the "w32api" scheme.  The reason is that this
> >requires no changes at all to the gcc specs file.  Rather, the Cygwin
> >gcc package would simply create matching symlinks:
> >
> >  ln -s /usr/share/windows_psdk/include /usr/include/w32api
> >  ln -s /usr/share/windows_psdk/lib     /usr/lib/w32api
> >  ln -s /usr/share/windows_psdk/lib64   /usr/lib64/w32api
> 
> I think it's pretty unusual to install libraries and headers in
> /usr/share, particularly in the case of libraries.  gcc/linux has
> conventions for this type of thing.  I broke them when I installed
> headers and libraries in /usr/include/w32api.  I don't think we should
> stray further by putting things in /usr/share.

Well, you have two choices, basically:

- Either keep the files in /usr/{include,lib,lib64}/w32api, which requires
  to duplicate the files as it is done today,

- or keep only one copy of the files in well-known places and create
  the various w32api's as symlinks to these well-known places.

My stance is that we should give up the unnecessary duplication of the
files.  Then the question is just, where to install the shared platform
files so that they are accessible from all affected compilers, the Cygwin
GCCs as well as the Mingw64 GCCs.  IMO /usr/share is the right place
for everything which is shared between multiple packages.  And if all
compilers use symlinks, it doesn't really matter where the shared files
are.  If /usr/share turns out to be not quite right, you can easily
move them around and just fix the symlinks.

> Could Dave Korn weigh in on this?

Yes, that would be helpful, probably.


Corinna

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

Re: Mingw64 and Cygwin: header and libs layout

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

On 3/13/2012 22:00, Corinna Vinschen wrote:
> On Mar 13 09:51, Christopher Faylor wrote:
>> On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
>>> Hi Kai,
>>>
>>> On Mar 13 14:25, Kai Tietz wrote:
>>>> Hi Corinna,
>>>>
>>>> I suggest the approach to install for cygwin the platform-headers to a
>>>> shared place.  I suggest that mingw-w64 adds to configure for headers
>>>> and crt an option, which installs platform-headers/libraries to
>>>> '/usr/shared/psdk_windows' location.  Means under this path are the
>>>> folders lib/lib64/include containing only the platform-parts.
>>>
>>> That sounds like an excellent idea to me!
>>>
>>>> For the cygwin-based mingw-w64 cross-compiler we need to add here by
>>>> spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
>>>> should be a special configuration option for gcc (and binutils), which
>>>> adds the required parts to spec-files.
>>>
>>> IMHO we should keep the "w32api" scheme.  The reason is that this
>>> requires no changes at all to the gcc specs file.  Rather, the Cygwin
>>> gcc package would simply create matching symlinks:
>>>
>>>  ln -s /usr/share/windows_psdk/include /usr/include/w32api
>>>  ln -s /usr/share/windows_psdk/lib     /usr/lib/w32api
>>>  ln -s /usr/share/windows_psdk/lib64   /usr/lib64/w32api
>>
>> I think it's pretty unusual to install libraries and headers in
>> /usr/share, particularly in the case of libraries.  gcc/linux has
>> conventions for this type of thing.  I broke them when I installed
>> headers and libraries in /usr/include/w32api.  I don't think we should
>> stray further by putting things in /usr/share.
> 
> Well, you have two choices, basically:
> 
> - Either keep the files in /usr/{include,lib,lib64}/w32api, which requires
>   to duplicate the files as it is done today,
> 
> - or keep only one copy of the files in well-known places and create
>   the various w32api's as symlinks to these well-known places.
> 
> My stance is that we should give up the unnecessary duplication of the
> files.  Then the question is just, where to install the shared platform
> files so that they are accessible from all affected compilers, the Cygwin
> GCCs as well as the Mingw64 GCCs.  IMO /usr/share is the right place
> for everything which is shared between multiple packages.  And if all
> compilers use symlinks, it doesn't really matter where the shared files
> are.  If /usr/share turns out to be not quite right, you can easily
> move them around and just fix the symlinks.
> 

Personally, I think it'll be better too for the mingw-w64 cross
compilers (I should really update them about now). TWith /usr/share
install, they can now share a common set of headers/libs instead of
duplicating the files.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: Mingw64 and Cygwin: header and libs layout

[Charles Wilson]

On 3/13/2012 10:00 AM, Corinna Vinschen wrote:
> - Either keep the files in /usr/{include,lib,lib64}/w32api, which requires
>   to duplicate the files as it is done today,

I don't think it's THAT big a burden for (Chris S.|Joy Y.) to create two
different packages for (mingw32|mingw64-platform).  But I could be
wrong...obviously Chris and Jon's opinions should have a major impact on
this decision.

> My stance is that we should give up the unnecessary duplication of the
> files.  Then the question is just, where to install the shared platform
> files so that they are accessible from all affected compilers, the Cygwin
> GCCs as well as the Mingw64 GCCs.  IMO /usr/share is the right place
> for everything which is shared between multiple packages. 

Err, well -- technically /usr/share is for platform-independent files. I
*guess* you could say that, in the realm of cygwin|mingw32|mingw64, the
platform headers and libs are (supposed to be) "platform independent" --
within that small realm of platforms.

But...not really appropriate for, say, solaris or linux, right?  So a
strict interpretation says they should not go into /usr/share/.

Platform-dependent files, even headers, tend to go into /usr/lib under
some subdirectory (think /usr/lib/gcc/*/include/ -- or
./usr/lib/glib/include, /usr/lib/perl5/*/CORE/*.h, etc.

So, I could see
  /usr/lib/platform/include/*.h
  /usr/lib/platform/[lib/ ?]/*.a
  /usr/lib64/platform/include/*.h
  /usr/lib64/platform/[lib/ ?]/*.a
or somesuch.

>> Could Dave Korn weigh in on this?
> 
> Yes, that would be helpful, probably.

Yep.

--
Chuck

Re: Mingw64 and Cygwin: header and libs layout

[Dave Korn]

On 13/03/2012 10:10, Corinna Vinschen wrote:

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

  The generic solution for the future cygwin64-targeted GCC will of course be
to not refer to the mingw64 headers at all!

On 13/03/2012 13:51, Christopher Faylor wrote:
> On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
>> On Mar 13 14:25, Kai Tietz wrote:

>>> I suggest the approach to install for cygwin the platform-headers to a
>>> shared place.  I suggest that mingw-w64 adds to configure for headers
>>> and crt an option, which installs platform-headers/libraries to
>>> '/usr/shared/psdk_windows' location.  Means under this path are the
>>> folders lib/lib64/include containing only the platform-parts.
>> That sounds like an excellent idea to me!
>>
>>> For the cygwin-based mingw-w64 cross-compiler we need to add here by
>>> spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
>>> should be a special configuration option for gcc (and binutils), which
>>> adds the required parts to spec-files.
>> IMHO we should keep the "w32api" scheme.  The reason is that this
>> requires no changes at all to the gcc specs file.  Rather, the Cygwin
>> gcc package would simply create matching symlinks:
>>
>>  ln -s /usr/share/windows_psdk/include /usr/include/w32api
>>  ln -s /usr/share/windows_psdk/lib     /usr/lib/w32api
>>  ln -s /usr/share/windows_psdk/lib64   /usr/lib64/w32api
>
> I think it's pretty unusual to install libraries and headers in
> /usr/share, particularly in the case of libraries.  gcc/linux has
> conventions for this type of thing.  I broke them when I installed
> headers and libraries in /usr/include/w32api.  I don't think we should
> stray further by putting things in /usr/share.
>
> Could Dave Korn weigh in on this?

  I'd find it a bit odd as well, but can't really think of an actual problem,
it just gives me a mild bit of cognitive dissonance.  It's an unusual
situation to want to share a set of headers but not the corresponding libs,
and doesn't work well with the standard $prefix/{lib,include} pattern.  The
headers for w32api aren't huge in terms of disk space (5.5M), so just having
duplicates in the appropriate places wouldn't be that bad.  It's what happens
every time you build libwhatever for both your native system and a
cross-target anyway.

  Is there ever any likelihood that the w32api team might want to implement
autoconfigury-based customisations to the installed headers based on the
detected properties of the host platform (n.b. using 'host' in the library
sense, i.e. the same as 'target' for the compiler)?  Sharing them between the
two compilers would lock that out.

  (BTW, I noticed that gcc 4.7.0 was released, so I'll try and get a test
package up over the next fortnight or so).

    cheers,
      DaveK

Re: Mingw64 and Cygwin: header and libs layout

[Corinna Vinschen]

On Mar 24 18:12, Dave Korn wrote:
> On 13/03/2012 10:10, Corinna Vinschen wrote:
> 
> > 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.
> 
>   The generic solution for the future cygwin64-targeted GCC will of course be
> to not refer to the mingw64 headers at all!

Huh?

> On 13/03/2012 13:51, Christopher Faylor wrote:
> > On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote:
> >> On Mar 13 14:25, Kai Tietz wrote:
> 
> >>> I suggest the approach to install for cygwin the platform-headers to a
> >>> shared place.  I suggest that mingw-w64 adds to configure for headers
> >>> and crt an option, which installs platform-headers/libraries to
> >>> '/usr/shared/psdk_windows' location.  Means under this path are the
> >>> folders lib/lib64/include containing only the platform-parts.
> >> That sounds like an excellent idea to me!
> >>
> >>> For the cygwin-based mingw-w64 cross-compiler we need to add here by
> >>> spec (for headers in gcc and for libs in binutils or gcc).  IMHO this
> >>> should be a special configuration option for gcc (and binutils), which
> >>> adds the required parts to spec-files.
> >> IMHO we should keep the "w32api" scheme.  The reason is that this
> >> requires no changes at all to the gcc specs file.  Rather, the Cygwin
> >> gcc package would simply create matching symlinks:
> >>
> >>  ln -s /usr/share/windows_psdk/include /usr/include/w32api
> >>  ln -s /usr/share/windows_psdk/lib     /usr/lib/w32api
> >>  ln -s /usr/share/windows_psdk/lib64   /usr/lib64/w32api
> >
> > I think it's pretty unusual to install libraries and headers in
> > /usr/share, particularly in the case of libraries.  gcc/linux has
> > conventions for this type of thing.  I broke them when I installed
> > headers and libraries in /usr/include/w32api.  I don't think we should
> > stray further by putting things in /usr/share.
> >
> > Could Dave Korn weigh in on this?
> 
>   I'd find it a bit odd as well, but can't really think of an actual problem,
> it just gives me a mild bit of cognitive dissonance.  It's an unusual
> situation to want to share a set of headers but not the corresponding libs,
> and doesn't work well with the standard $prefix/{lib,include} pattern.

Sorry, but I don't understand what you mean.  Of course we would like
to share headers *and* libs.  See above.  The include files are the
same for 32 and 64 bit, while the libs are obviously different.  Therefore
it makes sense to create a shared directory which contains the shared include
files as well as the different libs for the different platforms.

My idea is to keep the w32api "subdirs" under /usr/include and /usr/lib,
and add a new one under /usr/lib64.  These could be implemented as real
subdirs, or as symlinks to, for instance,
/usr/share/windows_psdk/{include,lib,lib64}, as outlined above.

Sticking to the w32api subdir/symlinks allows to keep up the standard
specs file for the Cygwin compiler.  Additionally it would allow to
stick to the Cygwin ld from binutils "as is", since it has the w32api
path hardcoded.

The question is just where to keep the actual include and lib files in
this scenario, and Kai's suggestion was to keep them under
/usr/share/windows_psdk.

> headers for w32api aren't huge in terms of disk space (5.5M), so just having
> duplicates in the appropriate places wouldn't be that bad.  It's what happens
> every time you build libwhatever for both your native system and a
> cross-target anyway.

So you opt for the current layout with duplicated include and lib files,
just with Mingw64 instead of Mingw32 files?

>   Is there ever any likelihood that the w32api team might want to implement
> autoconfigury-based customisations to the installed headers based on the
> detected properties of the host platform (n.b. using 'host' in the library
> sense, i.e. the same as 'target' for the compiler)?  Sharing them between the
> two compilers would lock that out.

This is about using the Mingw64 headers, not the w32api headers from
Mingw32.  And the 32 and 64 bit headers are the same.  Platform
differences are handled via target macros.


Corinna

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

Re: Mingw64 and Cygwin: header and libs layout

[Dave Korn]

On 24/03/2012 19:19, Corinna Vinschen wrote:
> On Mar 24 18:12, Dave Korn wrote:
>> On 13/03/2012 10:10, Corinna Vinschen wrote:
>>
>>> 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.
>>   The generic solution for the future cygwin64-targeted GCC will of course be
>> to not refer to the mingw64 headers at all!
> 
> Huh?

  Just like the current i686-pc-cygwin-gcc does not refer to mingw32 headers,
a future theoretical x86_86-pc-cygwin64-gcc will not refer to mingw64 headers,
because we'll have a proper native compiler rather than having to rely on a
cross-compiler that is almost - but not quite - correct.

> Sorry, but I don't understand what you mean.  Of course we would like
> to share headers *and* libs.  See above.

  OK, then I clearly don't understand what you mean.  Didn't this thread start
with you pointing out that, although the same headers were valid for cygwin or
mingw, the startup crt .o files and libs weren't right?  How can the cygwin .o
files possibly be compatible with the mingw ones?

>   The include files are the
> same for 32 and 64 bit, while the libs are obviously different.

  So why do you want to share the libs, since they are different?

>  Therefore
> it makes sense to create a shared directory which contains the shared include
> files as well as the different libs for the different platforms.

  Ah, well, not to me it doesn't.  To me, what makes sense is
(headers+libs)*different.platforms, not (headers)*different.platforms +
(libs)*different.platforms, and this is what the entire GNU/Linux/Unix $prefix
structure assumes.  I think this is a little bit like big-endian vs.
little-endian arguments: should the library itself be the most significant
part, or the target?  Regardless the arguments one way or another, the GNU
system has already adopted the decision that $target is the most-significant
part of a $prefix layout.

> My idea is to keep the w32api "subdirs" under /usr/include and /usr/lib,
> and add a new one under /usr/lib64.  These could be implemented as real
> subdirs, or as symlinks to, for instance,
> /usr/share/windows_psdk/{include,lib,lib64}, as outlined above.
> 
> The question is just where to keep the actual include and lib files in
> this scenario, and Kai's suggestion was to keep them under
> /usr/share/windows_psdk.

  What you're implying there, is that from now forever onward, the cygwin
w32api and cross-mingw-w32api packages always have to be kept in perfect
lock-step, if there's only going to be one set of headers for two sets of
libs.  That seems like a potential source of incompatibilities to me; as I was
trying to suggest in my comment about autoconfig-customised variants of the
headers, it may one day be the case that the headers for one set of libs have
to actually say something different from the headers for the other set of
libs, and we're tying our own hands in advance if we decide that one common
set of headers has to serve the same lib for two separate targets.

>> headers for w32api aren't huge in terms of disk space (5.5M), so just having
>> duplicates in the appropriate places wouldn't be that bad.  It's what happens
>> every time you build libwhatever for both your native system and a
>> cross-target anyway.
> 
> So you opt for the current layout with duplicated include and lib files,
> just with Mingw64 instead of Mingw32 files?

  Yes, I think it's a perfectly acceptable compromise.

>>   Is there ever any likelihood that the w32api team might want to implement
>> autoconfigury-based customisations to the installed headers based on the
>> detected properties of the host platform (n.b. using 'host' in the library
>> sense, i.e. the same as 'target' for the compiler)?  Sharing them between the
>> two compilers would lock that out.
> 
> This is about using the Mingw64 headers, not the w32api headers from
> Mingw32.  And the 32 and 64 bit headers are the same.  Platform
> differences are handled via target macros.

  Well, as long as we can *guarantee* for ever that that will always be the
case, we could indeed make some complicated scheme to share the headers work,
but really, for the sake of five meg of disk space, I don't see why it's worth
the risk or effort.

  Let me summarise what I think: I think we should treat the x-cygwin
(==native) and x-mingw targets as if they were utterly entirely separate, just
like any two other random hosts/targets in the entire gnu infrastructure, and
simply not worry about one tiny disk-space optimisation that we could perhaps
make, at the expense of a good deal of other complications, some actual, some
potential.  We should treat w32api as an external lib, and mingw should treat
it as their native C lib, and everything else should flow from that.

    cheers,
      DaveK

Re: Mingw64 and Cygwin: header and libs layout

[Corinna Vinschen]

On Mar 24 22:59, Dave Korn wrote:
> On 24/03/2012 19:19, Corinna Vinschen wrote:
> > On Mar 24 18:12, Dave Korn wrote:
> >> On 13/03/2012 10:10, Corinna Vinschen wrote:
> >>
> >>> 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.
> >>   The generic solution for the future cygwin64-targeted GCC will of course be
> >> to not refer to the mingw64 headers at all!
> > 
> > Huh?
> 
>   Just like the current i686-pc-cygwin-gcc does not refer to mingw32 headers,

It does.

  $ gcc -dumpspecs | grep w32api
  %(cpp_cpu) %{posix:-D_POSIX_SOURCE}   %{mno-win32:%{mno-cygwin: %emno-cygwin and mno-win32 are not compatible}}   %{mno-cygwin:-D__MSVCRT__ -D__MINGW32__ %{!ansi:%{mthreads:-D_MT}}}  %{!mno-cygwin:-D__CYGWIN32__ -D__CYGWIN__ %{!ansi:-Dunix} -D__unix__ -D__unix }  %{mwin32|mno-cygwin:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ %{!ansi:-DWINNT}}  %{!nostdinc:%{!mno-win32|mno-cygwin:-idirafter ../include/w32api%s -idirafter ../../include/w32api%s}}

> a future theoretical x86_86-pc-cygwin64-gcc will not refer to mingw64 headers,
> because we'll have a proper native compiler rather than having to rely on a
> cross-compiler that is almost - but not quite - correct.
> 
> > Sorry, but I don't understand what you mean.  Of course we would like
> > to share headers *and* libs.  See above.
> 
>   OK, then I clearly don't understand what you mean.  Didn't this thread start
> with you pointing out that, although the same headers were valid for cygwin or
> mingw, the startup crt .o files and libs weren't right?  How can the cygwin .o
> files possibly be compatible with the mingw ones?

Uh, that's a misconception.  I was talking about the platform headers and
libs, not the Mingw64 CRT headers and libs.  The platform headers and libs
are what is known as w32api so far.  What I'm talking about all the time
is *only* the platform part.  The mingw64 specific headers and libs should
stay were they are today, in the /usr/{$target}-w64-mingw32/ subdirs.

Does that make things clearer now?  I'm a bit puzzeled because
throughout this thread we're refering to w32api subdirs or symlinks, not
mingw32 subdirs or symlinks.  Of course we have no reason to use
Mingw{32,64} CRT headers and libs.

OTOH we *must* have access to the w32api libs, because we can't generate
running apps without linking at least against kernel32 (for crtbegin.o).

> >   The include files are the
> > same for 32 and 64 bit, while the libs are obviously different.
> 
>   So why do you want to share the libs, since they are different?

See above.

> >  Therefore
> > it makes sense to create a shared directory which contains the shared include
> > files as well as the different libs for the different platforms.
> 
>   Ah, well, not to me it doesn't.  To me, what makes sense is
> (headers+libs)*different.platforms, not (headers)*different.platforms +
> (libs)*different.platforms, and this is what the entire GNU/Linux/Unix $prefix
> structure assumes.

Again, this is only about shareing the plaform stuff.  If we keep
/usr/include/w32api, /usr/lib/w32api, and /usr/lib64/w32api as symlinks,
does it really matter where the files actually are?

> I think this is a little bit like big-endian vs.
> little-endian arguments: should the library itself be the most significant
> part, or the target?  Regardless the arguments one way or another, the GNU
> system has already adopted the decision that $target is the most-significant
> part of a $prefix layout.
> 
> > My idea is to keep the w32api "subdirs" under /usr/include and /usr/lib,
> > and add a new one under /usr/lib64.  These could be implemented as real
> > subdirs, or as symlinks to, for instance,
> > /usr/share/windows_psdk/{include,lib,lib64}, as outlined above.
> > 
> > The question is just where to keep the actual include and lib files in
> > this scenario, and Kai's suggestion was to keep them under
> > /usr/share/windows_psdk.
> 
>   What you're implying there, is that from now forever onward, the cygwin
> w32api and cross-mingw-w32api packages always have to be kept in perfect
> lock-step, if there's only going to be one set of headers for two sets of
> libs.  That seems like a potential source of incompatibilities to me; as I was
> trying to suggest in my comment about autoconfig-customised variants of the
> headers, it may one day be the case that the headers for one set of libs have
> to actually say something different from the headers for the other set of
> libs, and we're tying our own hands in advance if we decide that one common
> set of headers has to serve the same lib for two separate targets.

And why should this be done?  It doesn't look as if Microsoft will ever
generate autoconf'ed, target-specific headers in different directories
and Mingw64 strives to create platform headers in as most compatible as
possible.  Kai, what do you say

And then, if we stick to the assumption that the platform headers will
be target dependent at one point, How would you like to solve that for
the Cygwin gcc?  Introducing /usr/include/w64api?  As dir or as symlink?

> >> headers for w32api aren't huge in terms of disk space (5.5M), so just having
> >> duplicates in the appropriate places wouldn't be that bad.  It's what happens
> >> every time you build libwhatever for both your native system and a
> >> cross-target anyway.
> > 
> > So you opt for the current layout with duplicated include and lib files,
> > just with Mingw64 instead of Mingw32 files?
> 
>   Yes, I think it's a perfectly acceptable compromise.
> 
> >>   Is there ever any likelihood that the w32api team might want to implement
> >> autoconfigury-based customisations to the installed headers based on the
> >> detected properties of the host platform (n.b. using 'host' in the library
> >> sense, i.e. the same as 'target' for the compiler)?  Sharing them between the
> >> two compilers would lock that out.
> > 
> > This is about using the Mingw64 headers, not the w32api headers from
> > Mingw32.  And the 32 and 64 bit headers are the same.  Platform
> > differences are handled via target macros.
> 
>   Well, as long as we can *guarantee* for ever that that will always be the
> case, we could indeed make some complicated scheme to share the headers work,
> but really, for the sake of five meg of disk space, I don't see why it's worth
> the risk or effort.
> 
>   Let me summarise what I think: I think we should treat the x-cygwin
> (==native) and x-mingw targets as if they were utterly entirely separate, just
> like any two other random hosts/targets in the entire gnu infrastructure, and
> simply not worry about one tiny disk-space optimisation that we could perhaps
> make, at the expense of a good deal of other complications, some actual, some
> potential.  We should treat w32api as an external lib, and mingw should treat
> it as their native C lib, and everything else should flow from that.

In that case you *have* to make a target specific headers assumption,
otherwise you have a break in the systematics.  And then, again, how do
you let the gcc compiler access the target headers?  By creating two
subdirs under /usr/include, w32api and w64api?


Corinna

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

Re: Mingw64 and Cygwin: header and libs layout

[Kai Tietz]

2012/3/25 Corinna Vinschen:
> And why should this be done?  It doesn't look as if Microsoft will ever
> generate autoconf'ed, target-specific headers in different directories
> and Mingw64 strives to create platform headers in as most compatible as
> possible.  Kai, what do you say

Well, for the platform headers - and this is all we are talking about
here AFAIU - it isn't to be expected that there are differences
between native-windows gcc version or Cygwin-gcc version, which can't
be covered by simple type-abstraction.  In general the psdk in cygwin
is required for linking, and in some situation also for building.

And of course it is obvious that C-runtime parts of headers and lib
have not to be installed in shared location.  This doesn't make any
sense to mix them.

> And then, if we stick to the assumption that the platform headers will
> be target dependent at one point, How would you like to solve that for
> the Cygwin gcc?  Introducing /usr/include/w64api?  As dir or as symlink?

 Platform headers (at least that one for Windows) aren't target
 dependent in general.  I think it would be even more a major flaw, if
 we would introduce such a difference.

>> >> headers for w32api aren't huge in terms of disk space (5.5M), so just having
>> >> duplicates in the appropriate places wouldn't be that bad.  It's what happens
>> >> every time you build libwhatever for both your native system and a
>> >> cross-target anyway.
> In that case you *have* to make a target specific headers assumption,
> otherwise you have a break in the systematics.  And then, again, how do
> you let the gcc compiler access the target headers?  By creating two
> subdirs under /usr/include, w32api and w64api?

 Yes, these target-specific assumptions in gcc caused in the past
 already enough pain for none-in-souirceware-tree targets.  I really
 would love if we could avoid such and infrastructural assumptions
 valid only for one target.

I see no good reason to make for 32-bit/64-bit (well, we might get in
near future even ARM support in platform-headers) platform environment
two different directories.  It just makes it more likely that headers
from one getting incompatible to the other-one.  Also it makes a
multilib-scenario (if ever desired for Cygwin) much harder. That
import-libaries (plus additional objects in imports) of platform-sdk
have to be placed in different lib-folders (lib32/lib64) is as obvious
as  the built of the platform-libraries are requiring an native
windows-compiler.
The platform-headers (without the DDK and the direct-x specific
extensions) are about 10 MB, nevertheless I agree that in modern times
of huge HDD-capacities a double installation of them isn't that worse
as it was in the past.

> Corinna

Regards,
Kai