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


> 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

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