* Mingw64 and Cygwin: header and libs layout @ 2012-03-13 10:11 Corinna Vinschen 2012-03-13 13:25 ` Kai Tietz 2012-03-24 18:12 ` Dave Korn 0 siblings, 2 replies; 12+ messages in thread From: Corinna Vinschen @ 2012-03-13 10:11 UTC (permalink / raw) To: JonY, Chris Sutcliffe; +Cc: cygwin-apps Hi Jon, Hi Chris, Hi all others, I'm working on building Cygwin with Mingw64 as the earliest stage in moving Cygwin to 64 bit. Obviously it doesn't make a lot of sense to build 32 bit Cygwin with Mingw32/w32api and 64 bit Cygwin with Mingw64. Therefore the w32api package will probably have to be replaced at one point. Please note that I'm not talking about the source repository here, but about the state after installation. The source repository is an entirely different problem. Anyway, I came across the problem that the Mingw64 header files are not split in platform headers and mingw64 specific CRT headers. The problem is that the CRT headers collide with the headers of the same name from newlib and Cygwin, so it's kind of bad to have them in the include search path. 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. More or less the same problem comes up with the libs. We have a couple of clashes, for instance binmode.o, libm.a, libpthread.a. Given that the Mingw64 project differs between CRT and platform headers in the repository, and they are only merged into the same include directory at install time, I was wondering if that couldn't be changed, and perhaps even really soon to avoid problems later on. Here's what I have in mind: - Right now, the Mingw32 w32api headers are installed into two places: /usr/i686-pc-mingw32/sys-root/mingw/include for the Mingw32 cross GCC /usr/include/w32api for Cygwin's GCC. Analogous for /usr/lib/w32api - Remove /usr/include/w32api and /usr/lib/w32api. - The Mingw64 headers get split into platform headers and CRT headers, for instance into /usr/i686-w64-mingw32/sys-root/mingw/{include,lib} (CRT) /usr/i686-w64-mingw32/sys-root/w32api/{include,lib} (Platform) /usr/x86_64-w64-mingw32/sys-root/mingw/{include,lib} (CRT) /usr/x86_64-w64-mingw32/sys-root/w32api/{include,lib} (Platform) - The Mingw64 cross-GCCs get spec files which take the splitting into account, just like the Cygwin GCC today has the /usr/include and the /usr/include/w32api paths in the include search path list by default (analogous for the libs). - In Cygwin we create symlinks by default, for instance in the GCC package: ln -s /usr/i686-w64-mingw32/sys-root/w32api/include /usr/include/w32api ln -s /usr/x86_64-w64-mingw32/sys-root/w32api/include /usr/include/w64api ln -s /usr/i686-w64-mingw32/sys-root/w32api/lib /usr/lib/w32api ln -s /usr/x86_64-w64-mingw32/sys-root/w32api/lib /usr/lib64/w64api Ok, that's it, basically. The advantage is that at one point the w32api directories could be replaced, but the Cygwin GCC would still work as before. Is that ok? Or shall we solve the problem in a different way? For instance: - Create new packages from the Mingw64 repo which install the platform headers and libs into /usr/{include,lib}/{w32api,w64api}, just like the w32api package today. - Or, drop the /usr/{include,lib}/w32api (and /usr/{include,lib64}/w64api) symlinks or dirs entirely, and let the w32api replacement package install the platform headers and libs directly into /usr/include and /usr/lib{64}. Or... any better idea? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 10:11 Mingw64 and Cygwin: header and libs layout Corinna Vinschen @ 2012-03-13 13:25 ` Kai Tietz 2012-03-13 13:37 ` Corinna Vinschen 2012-03-24 18:12 ` Dave Korn 1 sibling, 1 reply; 12+ messages in thread From: Kai Tietz @ 2012-03-13 13:25 UTC (permalink / raw) To: cygwin-apps, JonY, Chris Sutcliffe Hi Corinna, 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. 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. The CRT libraries and headers should stay IMHO in private places for toolchain. There is no need to put them under different locations or to have them at shared-locations AFAICS., as cygwin-toolchain won't provide this '-mno-cygwin' approach. So toolchains are regarding their CRT-headers isolated. Regards, Kai ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 13:25 ` Kai Tietz @ 2012-03-13 13:37 ` Corinna Vinschen 2012-03-13 13:51 ` Christopher Faylor 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2012-03-13 13:37 UTC (permalink / raw) To: cygwin-apps Hi Kai, On Mar 13 14:25, Kai Tietz wrote: > Hi Corinna, > > 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 > The CRT libraries and headers should stay IMHO in private places for > toolchain. There is no need to put them under different locations or > to have them at shared-locations AFAICS., as cygwin-toolchain won't > provide this '-mno-cygwin' approach. So toolchains are regarding > their CRT-headers isolated. Absolutely. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 13:37 ` Corinna Vinschen @ 2012-03-13 13:51 ` Christopher Faylor 2012-03-13 14:01 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Christopher Faylor @ 2012-03-13 13:51 UTC (permalink / raw) To: cygwin-apps On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote: >Hi Kai, > >On Mar 13 14:25, Kai Tietz wrote: >> Hi Corinna, >> >> 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? cgf ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 13:51 ` Christopher Faylor @ 2012-03-13 14:01 ` Corinna Vinschen 2012-03-13 22:48 ` JonY 2012-03-16 17:20 ` Charles Wilson 0 siblings, 2 replies; 12+ messages in thread From: Corinna Vinschen @ 2012-03-13 14:01 UTC (permalink / raw) To: cygwin-apps On Mar 13 09:51, Christopher Faylor wrote: > On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote: > >Hi Kai, > > > >On Mar 13 14:25, Kai Tietz wrote: > >> Hi Corinna, > >> > >> 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. Well, you have two choices, basically: - Either keep the files in /usr/{include,lib,lib64}/w32api, which requires to duplicate the files as it is done today, - or keep only one copy of the files in well-known places and create the various w32api's as symlinks to these well-known places. My stance is that we should give up the unnecessary duplication of the files. Then the question is just, where to install the shared platform files so that they are accessible from all affected compilers, the Cygwin GCCs as well as the Mingw64 GCCs. IMO /usr/share is the right place for everything which is shared between multiple packages. And if all compilers use symlinks, it doesn't really matter where the shared files are. If /usr/share turns out to be not quite right, you can easily move them around and just fix the symlinks. > Could Dave Korn weigh in on this? Yes, that would be helpful, probably. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 14:01 ` Corinna Vinschen @ 2012-03-13 22:48 ` JonY 2012-03-16 17:20 ` Charles Wilson 1 sibling, 0 replies; 12+ messages in thread From: JonY @ 2012-03-13 22:48 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 2798 bytes --] On 3/13/2012 22:00, Corinna Vinschen wrote: > On Mar 13 09:51, Christopher Faylor wrote: >> On Tue, Mar 13, 2012 at 02:36:21PM +0100, Corinna Vinschen wrote: >>> Hi Kai, >>> >>> On Mar 13 14:25, Kai Tietz wrote: >>>> Hi Corinna, >>>> >>>> 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. > > Well, you have two choices, basically: > > - Either keep the files in /usr/{include,lib,lib64}/w32api, which requires > to duplicate the files as it is done today, > > - or keep only one copy of the files in well-known places and create > the various w32api's as symlinks to these well-known places. > > My stance is that we should give up the unnecessary duplication of the > files. Then the question is just, where to install the shared platform > files so that they are accessible from all affected compilers, the Cygwin > GCCs as well as the Mingw64 GCCs. IMO /usr/share is the right place > for everything which is shared between multiple packages. And if all > compilers use symlinks, it doesn't really matter where the shared files > are. If /usr/share turns out to be not quite right, you can easily > move them around and just fix the symlinks. > Personally, I think it'll be better too for the mingw-w64 cross compilers (I should really update them about now). TWith /usr/share install, they can now share a common set of headers/libs instead of duplicating the files. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 196 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 14:01 ` Corinna Vinschen 2012-03-13 22:48 ` JonY @ 2012-03-16 17:20 ` Charles Wilson 1 sibling, 0 replies; 12+ messages in thread From: Charles Wilson @ 2012-03-16 17:20 UTC (permalink / raw) To: CygWin-Apps On 3/13/2012 10:00 AM, Corinna Vinschen wrote: > - Either keep the files in /usr/{include,lib,lib64}/w32api, which requires > to duplicate the files as it is done today, I don't think it's THAT big a burden for (Chris S.|Joy Y.) to create two different packages for (mingw32|mingw64-platform). But I could be wrong...obviously Chris and Jon's opinions should have a major impact on this decision. > My stance is that we should give up the unnecessary duplication of the > files. Then the question is just, where to install the shared platform > files so that they are accessible from all affected compilers, the Cygwin > GCCs as well as the Mingw64 GCCs. IMO /usr/share is the right place > for everything which is shared between multiple packages. Err, well -- technically /usr/share is for platform-independent files. I *guess* you could say that, in the realm of cygwin|mingw32|mingw64, the platform headers and libs are (supposed to be) "platform independent" -- within that small realm of platforms. But...not really appropriate for, say, solaris or linux, right? So a strict interpretation says they should not go into /usr/share/. Platform-dependent files, even headers, tend to go into /usr/lib under some subdirectory (think /usr/lib/gcc/*/include/ -- or ./usr/lib/glib/include, /usr/lib/perl5/*/CORE/*.h, etc. So, I could see /usr/lib/platform/include/*.h /usr/lib/platform/[lib/ ?]/*.a /usr/lib64/platform/include/*.h /usr/lib64/platform/[lib/ ?]/*.a or somesuch. >> Could Dave Korn weigh in on this? > > Yes, that would be helpful, probably. Yep. -- Chuck ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-13 10:11 Mingw64 and Cygwin: header and libs layout Corinna Vinschen 2012-03-13 13:25 ` Kai Tietz @ 2012-03-24 18:12 ` Dave Korn 2012-03-24 19:20 ` Corinna Vinschen 1 sibling, 1 reply; 12+ messages in thread From: Dave Korn @ 2012-03-24 18:12 UTC (permalink / raw) To: cygwin-apps 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). cheers, DaveK ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-24 18:12 ` Dave Korn @ 2012-03-24 19:20 ` Corinna Vinschen 2012-03-24 22:59 ` Dave Korn 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2012-03-24 19:20 UTC (permalink / raw) To: cygwin-apps 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? > 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 /usr/share/windows_psdk. > 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-24 19:20 ` Corinna Vinschen @ 2012-03-24 22:59 ` Dave Korn 2012-03-25 12:28 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Dave Korn @ 2012-03-24 22:59 UTC (permalink / raw) To: cygwin-apps 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, 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? > 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? > 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. 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. >> 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. cheers, DaveK ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Mingw64 and Cygwin: header and libs layout 2012-03-24 22:59 ` Dave Korn @ 2012-03-25 12:28 ` Corinna Vinschen [not found] ` <CAEwic4aBE6fn57ZGt2nM5bxxF8EDcB4e4XT8kGrEN6v=m-QFJA@mail.gmail.com> 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2012-03-25 12:28 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAEwic4aBE6fn57ZGt2nM5bxxF8EDcB4e4XT8kGrEN6v=m-QFJA@mail.gmail.com>]
* Re: Mingw64 and Cygwin: header and libs layout [not found] ` <CAEwic4aBE6fn57ZGt2nM5bxxF8EDcB4e4XT8kGrEN6v=m-QFJA@mail.gmail.com> @ 2012-03-26 9:55 ` Kai Tietz 0 siblings, 0 replies; 12+ messages in thread From: Kai Tietz @ 2012-03-26 9:55 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-03-26 9:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-13 10:11 Mingw64 and Cygwin: header and libs layout Corinna Vinschen 2012-03-13 13:25 ` Kai Tietz 2012-03-13 13:37 ` Corinna Vinschen 2012-03-13 13:51 ` Christopher Faylor 2012-03-13 14:01 ` Corinna Vinschen 2012-03-13 22:48 ` JonY 2012-03-16 17:20 ` Charles Wilson 2012-03-24 18:12 ` Dave Korn 2012-03-24 19:20 ` Corinna Vinschen 2012-03-24 22:59 ` Dave Korn 2012-03-25 12:28 ` Corinna Vinschen [not found] ` <CAEwic4aBE6fn57ZGt2nM5bxxF8EDcB4e4XT8kGrEN6v=m-QFJA@mail.gmail.com> 2012-03-26 9:55 ` Kai Tietz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).