Mingw64 and Cygwin: header and libs layout
Kai Tietz
ktietz70@googlemail.com
Mon Mar 26 09:55:00 GMT 2012
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
windows-compiler.
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
Regards,
Kai
More information about the Cygwin-apps
mailing list