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


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