Re: gcc4: next release (Dave Korn we need you)
On Jul 8 08:25, Charles Wilson wrote: On 7/8/2010 3:22 AM, Corinna Vinschen wrote: On Jul 7 18:24, Christopher Faylor wrote: [...] Whether we use w32api in the cygwin tree or from somewhere else really doesn't matter as long as Cygwin builds. That's why I'd like to know if Cygwin builds with w32api from the mingw64 project. Have you checked with Red Hat's lawyers concerning the use of mingw64's w32api to build their cygwin-based products? That's something I'll doo as soon as we really intend to switch the Cygwin build to mingw64's w32api. Right now, what I get from all the gory details, it's not that easy to keep mingw64's w32api headers and libs apart from the mingw headers and libs anyway. However, I won't object against having a version for the 64 bit gcc hidden in the cross-compiler tree, if there's no way around it. But *if* there's a way to keep just a single version, it should be exploited. I don't get this. There are three reasons to be concerned about multiple copies -- even if they are identical (which in this case they are not and can't be, esp. 64bit vs 32bit implibs). 1) disk space 2) things that should be identical (like headers for the OS's API) out of sync, or keeping them deliberately different 3) end user confusion You're missing number 4. Cygwin and Mingw are targeting the same underlying real target, which is Windows. Both systems use different approaches and both have their own set of libs and headers which only make sense in their own environment. But underneath they both run on Windows. For that reason my POV is that w32api is an intrinsic part of the system and that's why it belongs into /usr/include and /usr/lib. IMHO. If there's no way around it, I don't mind if we have multiple w32api, one for the system and one for each mingw cross compiler. I don't mind the disk space. I don't know beforehand which solution will result in more or less user confusion. So just go ahead. As for the path issue, I'd prefer to get a layout which closely resembles the Fedora mingw filesystem layout as in http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release (Dave Korn we need you)
On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: That's something I'll doo as soon as we really intend to switch the Cygwin build to mingw64's w32api. Right now, what I get from all the gory details, it's not that easy to keep mingw64's w32api headers and libs apart from the mingw headers and libs anyway. No, it's not. You're missing number 4. Cygwin and Mingw are targeting the same underlying real target, which is Windows. Both systems use different approaches and both have their own set of libs and headers which only make sense in their own environment. But underneath they both run on Windows. For that reason my POV is that w32api is an intrinsic part of the system and that's why it belongs into /usr/include and /usr/lib. IMHO. OTOH there are a number of packages out there that see windows.h in the default include path and say, Oh, this must be a Windows system! Let's use winsock/GDI/etc. which is often -- but not always -- incorrect on Cygwin. w32api may not be limited to cross-compiling, but having it in the default search path isn't always great either. If there's no way around it, I don't mind if we have multiple w32api, one for the system and one for each mingw cross compiler. I don't mind the disk space. I don't know beforehand which solution will result in more or less user confusion. So just go ahead. This will be much easier from the packaging perspective. As for the path issue, I'd prefer to get a layout which closely resembles the Fedora mingw filesystem layout as in http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. That is what I'm working with now. Yaakov
Re: gcc4: next release (Dave Korn we need you)
On Jul 12 05:25, Yaakov S wrote: On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: You're missing number 4. Cygwin and Mingw are targeting the same underlying real target, which is Windows. Both systems use different approaches and both have their own set of libs and headers which only make sense in their own environment. But underneath they both run on Windows. For that reason my POV is that w32api is an intrinsic part of the system and that's why it belongs into /usr/include and /usr/lib. IMHO. OTOH there are a number of packages out there that see windows.h in the default include path and say, Oh, this must be a Windows system! Let's use winsock/GDI/etc. which is often -- but not always -- incorrect on Cygwin. w32api may not be limited to cross-compiling, but having it in the default search path isn't always great either. Yeah, everything comes with a price tag. As for the path issue, I'd prefer to get a layout which closely resembles the Fedora mingw filesystem layout as in http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout. That is what I'm working with now. Nice. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release (Dave Korn we need you)
On 7/12/2010 8:02 AM, Corinna Vinschen wrote: On Jul 12 05:25, Yaakov S wrote: On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote: You're missing number 4. Cygwin and Mingw are targeting the same underlying real target, which is Windows. I wasn't actually missing it; I just considered this part of #2, but didn't fully express it: things that should be identical...out of sync. E.g. if it's all one OS, then all compilers should use identical headers. And, if they are (or should be) identical, then why not have a single common location? I understand that argument, but we're not sure they all really CAN be identical (e.g. the 64bit libs vs. the 32bit ones; the possible issue with mingw64 headers' provenance, etc). So, if there might be SOME differences, then... It makes sense to me, then, that each toolchain should provide, in a private area (e.g. sysroot), that version of the w32api libs and headers with which it has been tested. Rather than a hodge-podge where these two cross toolchains have their own custom w32api headers that they share between them but separate copies of the w32api libs; /that/ one has a custom w32api that isn't shared with anybody, but /this/ one shares w32api with cygwin's gcc... Ick.) Both systems use different approaches and both have their own set of libs and headers which only make sense in their own environment. But underneath they both run on Windows. For that reason my POV is that w32api is an intrinsic part of the system and that's why it belongs into /usr/include and /usr/lib. IMHO. I assume that you were not proposing to move the w32api headers from /usr/include/w32api/ into /usr/include/ proper, nor the libs from /usr/lib/w32api into /usr/lib proper, were you? If the cross toolchains provide their own w32api (and mingw-runtime) [or, for 64bit, mingw64-crt-headers and mingw64-crt-lib], then...the only remaining user of our current w32api api package is cygwin's own gcc (all versions). And the only remaining user of our current mingw-runtime packages is cygwin's gcc3 (and anything that might require /usr/bin/mingwm10.dll). So, after all of the cross compilers are deployed, we might think about what optimizations we could make with regards to how the non-toolchain-sysroot-specific w32api and mingw-runtime packages are...packaged. (The answer may be: make no changes.) But I don't want to start that discussion too early, so let's table it for now. OTOH there are a number of packages out there that see windows.h in the default include path and say, Oh, this must be a Windows system! Let's use winsock/GDI/etc. which is often -- but not always -- incorrect on Cygwin. w32api may not be limited to cross-compiling, but having it in the default search path isn't always great either. Yeah, everything comes with a price tag. Yep. I have to keep reminding people that #including windows.h will cause _WIN32 to be defined, and that #ifdef _WIN32 does not, actually, mean !CYGWIN... -- Chuck
Re: gcc4: next release (Dave Korn we need you)
On Jul 7 18:24, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 06:12:23PM -0400, Charles Wilson wrote: On 7/7/2010 5:03 PM, Christopher Faylor wrote: or as a cross-compiler. Huh? Do you mean that we use cygwin's gcc as a code generator, and turn off everything that makes it cygwin: I mean that *I* build the DLL with a cross compiler based on the released version of gcc. Yes, me too. I hate to say that but it is faster than building on Cygwin... [...] Whether we use w32api in the cygwin tree or from somewhere else really doesn't matter as long as Cygwin builds. That's why I'd like to know if Cygwin builds with w32api from the mingw64 project. Even after a night's sleep I still don't like the idea to hvae two versions of w32api in the distro. To me, w32api belongs into /usr/include. One version for everybody. w32api is *not* cross compiler specific, it's a resource for all three targets, Cygwin as well as 32 bit and 64 bit Mingw. However, I won't object against having a version for the 64 bit gcc hidden in the cross-compiler tree, if there's no way around it. But *if* there's a way to keep just a single version, it should be exploited. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release (Dave Korn we need you)
On 7/8/2010 3:22 AM, Corinna Vinschen wrote: On Jul 7 18:24, Christopher Faylor wrote: [...] Whether we use w32api in the cygwin tree or from somewhere else really doesn't matter as long as Cygwin builds. That's why I'd like to know if Cygwin builds with w32api from the mingw64 project. Have you checked with Red Hat's lawyers concerning the use of mingw64's w32api to build their cygwin-based products? Even after a night's sleep I still don't like the idea to hvae two versions of w32api in the distro. To me, w32api belongs into /usr/include. One version for everybody. w32api is *not* cross compiler specific, it's a resource for all three targets, Cygwin as well as 32 bit and 64 bit Mingw. Well, the 64bit build of w32api provides over 2000 import libraries. The 32bit build has only about 225. Apparently this is because the .def files that each are generated from are maintained separately, vetted on each system, and their contents *differ* on each system. Until recently, mingw64 focused mainly on 64bit support; 32bit efforts are much younger for them. So while the include/ bits may be the same for mingw64's w32api between 32bit and 64bit systems, the lib/ bits definitely differ. And, of course, they differ from the current cygwin/mingw.org 32bit version -- but that's a lot easier to fix than the headers IMO. (.def file contents don't appear to be as difficult to share between mingw64 and mingw.org, as far as this non-lawyer can tell. I mean, it's not like anybody could copy the .def file contents from the Windows SDK, so mingw.org doesn't need to worry about that). However, I won't object against having a version for the 64 bit gcc hidden in the cross-compiler tree, if there's no way around it. But *if* there's a way to keep just a single version, it should be exploited. I don't get this. There are three reasons to be concerned about multiple copies -- even if they are identical (which in this case they are not and can't be, esp. 64bit vs 32bit implibs). 1) disk space 2) things that should be identical (like headers for the OS's API) out of sync, or keeping them deliberately different 3) end user confusion IMO (1) is a non-issue. If you're going to install a cross compiler, some duplicated implibs and headers are the least of your concerns with regards to disk space. (2) -- well, if cygwin/Red Hat doesn't care about the where did you get that function declaration you mingw64 folks added to foo.h problem, then maybe the mingw64 w32api headers can be used by all of (mingw64-32bit, mingw64-64bit, mingw.org-32bit, cygwin) compilers. But the implibs will be distinct between the 64bit version and the 32bit version(s). But...even given that, I still don't see a real problem. Do we worry, when creating a sysroot for an embedded target on a linux $host, when compiling zlib, that we have two copies of zlib.h -- one in /usr/include, and another in /usr/my-embedded-toolchain/sysroot/usr/include? Do we worry that there are multiple copies of the glibc headers in both locations (or all of them, if I have several cross compilers)? Even when I'm using exactly the same version of glibc or zlib on both my development machine and the target, so the headers are, in fact, identical? No...that's just how cross compilers work! The sysroot for cross-compiler target A will probably contain lots of similar stuff, maybe even identical, to the sysroot for cross compiler target B, and similar to the stuff in the $host's sysroot /. (3) I think it's is hell of lot MORE confusing for our users, for us to foist a regime on them that says cross compilers should never access stuff in the system include or lib directories; that's cross-compiler 101. Except, of course, for /usr/include/w32api and /usr/lib/w32api -- and we've either patched all of our mingw* cross compilers to look there automatically behind your back in addition to its own sysroot, or you are expected to manually add the appropriate and completely non-intuitive -L/usr/lib/w32api -I/usr/include/w32api to your CROSS CPPFLAGS/LDFLAGS when building. Except for 64bit, where you should use -I/usr/include/w32api but not -L/usr/include/w32api. And never mind that that is completely DIFFERENT than how the same cross compiler toolchain would operate over on any other $host, so we get FAQs not just from total n00bs but also from people with lots of experience using linux-$hosted cross compilers. Ugh! And that's not even going into the issue of how, exactly, we are to 'tease out' the w32api-related PARTS of mingw64's separate mingw64-crt-include and mingw64-crt-lib trees, if we plan to share mingw64's w32api between cygwin|mingw.org, and mingw64-32, but (obviously) not the crt/mingw-runtime bits, as mingw64 has them all jumbled together. AND assuming you, and Red Hat, have no legal issues related to mingw64's w32api headers + cygwin. It'd be great if those legal concerns ARE unimportant, don't get me wrong. But I'd rather have a
Re: gcc4: next release (Dave Korn we need you)
On Thu, Jul 8, 2010 at 8:25 AM, Charles Wilson cyg...@cwilson.fastmail.fm wrote: Well, the 64bit build of w32api provides over 2000 import libraries. The 32bit build has only about 225. Apparently this is because the .def files that each are generated from are maintained separately, vetted on each system, and their contents *differ* on each system. Until recently, mingw64 focused mainly on 64bit support; 32bit efforts are much younger for them. So while the include/ bits may be the same for mingw64's w32api between 32bit and 64bit systems, the lib/ bits definitely differ. Just to clarify, we've had 32-bit support for a very long time, almost since the beginning. And, there are far fewer imports because there are far fewer libs to import by default.
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 07, 2010 at 10:22:17AM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-07-07 at 08:58 -0400, Christopher Faylor wrote: Unfortunately, it sounds like we've stepped into the middle of a dispute between the mingw folks and the mingw64 folks. Maybe the best thing for us to do would be to decide to use only one or the other but not both. It does seem that there is a debate -- but I'm not part of it. My only involvement with either the last few days is fixing cygport for cross-compilers and cross-compiling. That being said, I see the technical arguments for allowing both toolchains (provided someone steps up and packages a mingw.org version). Mingw.org-based software is still widespread, and as JonY mentioned they are not fully compatible. OTOH mingw-w64, besided providing the only 64bit option, also has certain advantages which warrant a 32bit version as well. But we're talking about the Cygwin community here. If we provide two different versions of the same thing we'll be clarifying forever. And, when I use humor after I've clarified to the same person three times in a row, we'll have a long thread about how mean I am for not answering the poor guy's question. No one wants that. I really wish Dave was here to weigh in. Here's my question, though: given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-cygwin (mingw-w64) toolchain be 100% compatible with current and past releases built with i686-pc-cygwin (mingw.org) toolchain? If not, then we need both. Is someone talking about a i686-w64-cygwin compiler? I thought this was entirely mingw. cgf
Re: gcc4: next release (Dave Korn we need you)
On Wed, 2010-07-07 at 11:33 -0400, Christopher Faylor wrote: Here's my question, though: given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-cygwin (mingw-w64) toolchain be 100% compatible with current and past releases built with i686-pc-cygwin (mingw.org) toolchain? If not, then we need both. Is someone talking about a i686-w64-cygwin compiler? I thought this was entirely mingw. You are correct; all these triplets are making my head spin. Let me rephrase: Given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-mingw32 (mingw-w64 32bit) toolchain be 100% compatible with current and past releases built with i686-pc-mingw32 (mingw.org) toolchain? If not, then we need both. Yaakov
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 07, 2010 at 11:16:54AM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-07-07 at 11:33 -0400, Christopher Faylor wrote: Here's my question, though: given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-cygwin (mingw-w64) toolchain be 100% compatible with current and past releases built with i686-pc-cygwin (mingw.org) toolchain? If not, then we need both. Is someone talking about a i686-w64-cygwin compiler? I thought this was entirely mingw. You are correct; all these triplets are making my head spin. Let me rephrase: Given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-mingw32 (mingw-w64 32bit) toolchain be 100% compatible with current and past releases built with i686-pc-mingw32 (mingw.org) toolchain? If not, then we need both. I suppose you could build cygwin with a mingw compiler but that's not how it's built now so I don't see why it makes a difference. cgf
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 7, 2010 at 12:53 PM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Wed, Jul 07, 2010 at 11:16:54AM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-07-07 at 11:33 -0400, Christopher Faylor wrote: Here's my question, though: given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-cygwin (mingw-w64) toolchain be 100% compatible with current and past releases built with i686-pc-cygwin (mingw.org) toolchain? If not, then we need both. Is someone talking about a i686-w64-cygwin compiler? I thought this was entirely mingw. You are correct; all these triplets are making my head spin. Let me rephrase: Given the incompatibilities mentioned, would a cygwin1.dll built with i686-w64-mingw32 (mingw-w64 32bit) toolchain be 100% compatible with current and past releases built with i686-pc-mingw32 (mingw.org) toolchain? If not, then we need both. I suppose you could build cygwin with a mingw compiler but that's not how it's built now so I don't see why it makes a difference. cgf How's it built now?
Re: gcc4: next release (Dave Korn we need you)
On 7 July 2010 18:27, NightStrike wrote: I suppose you could build cygwin with a mingw compiler but that's not how it's built now so I don't see why it makes a difference. cgf How's it built now? With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api. Andy
Re: gcc4: next release (Dave Korn we need you)
On 7 July 2010 22:03, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 09:44:14PM +0100, Andy Koppe wrote: On 7 July 2010 18:27, NightStrike wrote: I suppose you could build cygwin with a mingw compiler but that's not how it's built now so I don't see why it makes a difference. cgf How's it built now? With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api. It doesn't use -mno-cygwin. How could it? The build uses the latest gcc 4 which doesn't have that option. You're right of course. Is -nostdlib what ensures that the Cygwin DLL doesn't end up depending on itself, or is that a ridiculous notion in the first place? Andy
Re: gcc4: next release (Dave Korn we need you)
On 7/7/2010 5:03 PM, Christopher Faylor wrote:
On Wed, Jul 07, 2010 at 09:44:14PM +0100, Andy Koppe wrote:
On 7 July 2010 18:27, NightStrike wrote:
How's it built now?
With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api.
It doesn't use -mno-cygwin. How could it? The build uses the latest
gcc 4 which doesn't have that option. It uses the Cygwin gcc either
natively
Okay, with you so far.
or as a cross-compiler.
Huh? Do you mean that we use cygwin's gcc as a code generator, and turn
off everything that makes it cygwin:
(e.g. -nostartfiles -nodefaultlibs -nostdlib -nostartup -nostdinc
-nostdinc++ etc),
and -- because we build in a tree that includes w32api/ and mingw/ --
explicitly add those things that would make it a mingw compiler:
(e.g. -I ${srcdir}/winsup/w32api/include -I
${srcdir}/winsup/mingw/include -L ... ${builddir}/winsup/mingw/crt0.o etc)
I *think* that's what you meant -- but it's an odd definition of the
term cross compiler. It's more like: we've tied it up and tortured it
until it agrees to act like a cross compiler.
--
Chuck
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 7, 2010 at 6:12 PM, Charles Wilson
cyg...@cwilson.fastmail.fm wrote:
On 7/7/2010 5:03 PM, Christopher Faylor wrote:
On Wed, Jul 07, 2010 at 09:44:14PM +0100, Andy Koppe wrote:
On 7 July 2010 18:27, NightStrike wrote:
How's it built now?
With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api.
It doesn't use -mno-cygwin. How could it? The build uses the latest
gcc 4 which doesn't have that option. It uses the Cygwin gcc either
natively
Okay, with you so far.
or as a cross-compiler.
Huh? Do you mean that we use cygwin's gcc as a code generator, and turn off
everything that makes it cygwin:
(e.g. -nostartfiles -nodefaultlibs -nostdlib -nostartup -nostdinc
-nostdinc++ etc),
and -- because we build in a tree that includes w32api/ and mingw/ --
explicitly add those things that would make it a mingw compiler:
(e.g. -I ${srcdir}/winsup/w32api/include -I ${srcdir}/winsup/mingw/include
-L ... ${builddir}/winsup/mingw/crt0.o etc)
I *think* that's what you meant -- but it's an odd definition of the term
cross compiler. It's more like: we've tied it up and tortured it until it
agrees to act like a cross compiler.
--
Chuck
It probably just means that they build gcc on linux and specify
--target=i686-pc-cygwin in the gcc/binutils configure
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 07, 2010 at 06:12:23PM -0400, Charles Wilson wrote: On 7/7/2010 5:03 PM, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 09:44:14PM +0100, Andy Koppe wrote: On 7 July 2010 18:27, NightStrike wrote: How's it built now? With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api. It doesn't use -mno-cygwin. How could it? The build uses the latest gcc 4 which doesn't have that option. It uses the Cygwin gcc either natively Okay, with you so far. or as a cross-compiler. Huh? Do you mean that we use cygwin's gcc as a code generator, and turn off everything that makes it cygwin: I mean that *I* build the DLL with a cross compiler based on the released version of gcc. Others use the standard Cygwin gcc to build the dll and utilities. It's easy to see that we don't use -mno-cygwin or a mingw version of gcc to build the cygwin dll. And, obviously we need a cygwin version of gcc to build cygwin utilities like mount and ps. Whether we use w32api in the cygwin tree or from somewhere else really doesn't matter as long as Cygwin builds. cgf
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 07, 2010 at 06:22:30PM -0400, NightStrike wrote:
On Wed, Jul 7, 2010 at 6:12 PM, Charles Wilson
cyg...@cwilson.fastmail.fm wrote:
On 7/7/2010 5:03 PM, Christopher Faylor wrote:
On Wed, Jul 07, 2010 at 09:44:14PM +0100, Andy Koppe wrote:
On 7 July 2010 18:27, NightStrike wrote:
How's it built now?
With Cygwin gcc and the -mno-cygwin option, using mingw.org's w32api.
It doesn't use -mno-cygwin. ?How could it? ?The build uses the latest
gcc 4 which doesn't have that option. ?It uses the Cygwin gcc either
natively
Okay, with you so far.
or as a cross-compiler.
Huh? ?Do you mean that we use cygwin's gcc as a code generator, and turn off
everything that makes it cygwin:
(e.g. -nostartfiles ?-nodefaultlibs -nostdlib -nostartup -nostdinc
-nostdinc++ etc),
and -- because we build in a tree that includes w32api/ and mingw/ --
explicitly add those things that would make it a mingw compiler:
(e.g. -I ${srcdir}/winsup/w32api/include -I ${srcdir}/winsup/mingw/include
-L ... ${builddir}/winsup/mingw/crt0.o etc)
I *think* that's what you meant -- but it's an odd definition of the term
cross compiler. ?It's more like: we've tied it up and tortured it until it
agrees to act like a cross compiler.
It probably just means that they build gcc on linux and specify
--target=i686-pc-cygwin in the gcc/binutils configure
Yes, I believe that would be the standard definition of a
cross-compiler.
Maybe we can move on from this now?
cgf
