Re: Mingw64 and Cygwin: header and libs layout

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

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