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: Mingw64 and Cygwin: header and libs layout


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


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