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

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


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