Re: gcc4: next release
On 7/9/2010 01:09, Dave Korn wrote: On 07/07/2010 02:47, JonY wrote: I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything cygwin gets installed to /usr, however, with gcc 4.6, the locales data clashes. Yaakov suggested installing to /usr, but there are some problems with it. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Hmm, does this even happen when it is being built as a cross- rather than native- compiler? That would be a GCC bug if so; cross-compilers are meant not to look in the standard system directories as if they were native, see the docs for LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR, STANDARD_INCLUDE_DIR and INCLUDE_DEFAULTS(*) for full details. Well, cross GCC looks in /sysroot/mingw if that is what you mean. Locale data is also conflicting. So can't it just go in $prefix/$target/share instead of $prefix/share after a bit of fiddling with configure options? It could.
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 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 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 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 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 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 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 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
On Thu, 2010-07-08 at 18:27 -0400, NightStrike wrote: > 4.5.x ABI and 4.6.x ABI are what differ, not 4.5.0 and 4.5.1. > > There's no point in making the first shipped compiler have an ABI > that's already been changed. Hence 4.6. Kai said differently on #mingw-w64; apparently it was treated as a bugfix and allowed in for 4.5.1 as well. Yaakov
Re: gcc4: next release
On Thu, Jul 8, 2010 at 12:08 PM, Dave Korn wrote: >> GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying >> to avoid breaking user's self-built packages, so 4.5.0 and earlier is >> out of the question. The current 4.3.4 is too old for mingw-w64. > > Going with 4.5.1 seems the simplest solution. > > I'm slightly astonished though! How on earth did you manage to swing > permission to put an ABI-breaking backwardly-incompatible change on a release > branch? 4.5.x ABI and 4.6.x ABI are what differ, not 4.5.0 and 4.5.1. There's no point in making the first shipped compiler have an ABI that's already been changed. Hence 4.6.
Re: gcc4: next release (Dave Korn we need you)
On Thu, Jul 8, 2010 at 8:25 AM, Charles Wilson 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
On 07/07/2010 02:47, JonY wrote: > I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything > cygwin gets installed to /usr, however, with gcc 4.6, the locales data > clashes. > Yaakov suggested installing to /usr, but there are some problems with it. > > This makes GCC look in /usr/mingw regardless of what the toolchain > target is (anything matching mingw*), bad idea if we want a gcc 4 > mingw.org cross toolchain later. It can be fixed, but I'm not too sure > how yet. Hmm, does this even happen when it is being built as a cross- rather than native- compiler? That would be a GCC bug if so; cross-compilers are meant not to look in the standard system directories as if they were native, see the docs for LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR, STANDARD_INCLUDE_DIR and INCLUDE_DEFAULTS(*) for full details. > Locale data is also conflicting. So can't it just go in $prefix/$target/share instead of $prefix/share after a bit of fiddling with configure options? cheers, DaveK -- (*) - http://gcc.gnu.org/onlinedocs/gccint/Driver.html
Re: gcc4: next release
On 07/07/2010 02:47, JonY wrote: > Hello, > > Can I ask what will be the next version of GCC be in Cygwin? 4.5.0-1 if I'm snappy. 4.5.1-1 if I'm not. I plan to get back to it at the start of next week. > This makes GCC look in /usr/mingw regardless of what the toolchain > target is (anything matching mingw*), bad idea if we want a gcc 4 > mingw.org cross toolchain later. It can be fixed, but I'm not too sure > how yet. Locale data is also conflicting. Yaakov suggested that I sync > up with Cygwin GCC so the clash won't be so problematic, eg 4.5.0 Cygwin > with 4.5.1 branch snapshot for mingw-w64. > > GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying > to avoid breaking user's self-built packages, so 4.5.0 and earlier is > out of the question. The current 4.3.4 is too old for mingw-w64. Going with 4.5.1 seems the simplest solution. I'm slightly astonished though! How on earth did you manage to swing permission to put an ABI-breaking backwardly-incompatible change on a release branch? cheers, DaveK (still catching up with the backlog - I haven't finished reading this thread yet...)
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 w
Re: gcc4: next release
On Jul 7 21:17, Charles Wilson wrote: > On 7/7/2010 8:39 AM, Corinna Vinschen wrote: > > On Jul 7 08:08, Charles Wilson wrote: > >> I hope I have summed up the various competing proposals fairly, and that > >> this edition of my patented War and Peace emails helps move the > >> discussion along to a conclusion. > > > > Ok, I'm sufficiently confused now. So, here are a few questions. > > > > - Why do we need two different mingw's again? What are the merits of > > having mingw32 *and* mingw64-32? > > mingw32 and mingw64-32 are different. > [...] Ok, I'm not sure I get all this. I have no objections against having three mingw cross compilers, provided they are sufficently kept separate. I'm sure you guys will create the best possible solution here. I also do not care for the mingw headers and libs (mingw-runtime) which could or should be kept in the same tree as the cross compilers. I do care for w32api, but that's already in another mail... Corinna
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
On 7/7/2010 8:39 AM, Corinna Vinschen wrote: > On Jul 7 08:08, Charles Wilson wrote: >> I hope I have summed up the various competing proposals fairly, and that >> this edition of my patented War and Peace emails helps move the >> discussion along to a conclusion. > > Ok, I'm sufficiently confused now. So, here are a few questions. > > - Why do we need two different mingw's again? What are the merits of > having mingw32 *and* mingw64-32? mingw32 and mingw64-32 are different. This is true whether the mingw64-32 in question is provided by (a) "gcc -m32" where the gcc in question is a 64bit-by-default multilib gcc derived from mingw64's code, (b) "gcc" where the gcc in question is a 32bit-by-default multilib gcc derived from mingw64's code, or (c) a 32bit-only version of gcc derived from mingw64's code. However, the answer to your question differs depending on whether (a), (b), or (c) -- or some combination -- is true. For (a), Yaakov believes that "multilib makes sense for a 64bit compiler on a 32bit platform". The mingw64 guys have their own reasons for wanting to provide a multilib gcc, rather than simply two separate "single-lib" (?) compilers. Given those reasons for having "mingw64-32" -- kinda for "free" along with mingw64's unique 64bit contribution, the question becomes: why also provide mingw32? That boils down to the various differences between the two: the licensing and provenance issues connected with the two projects' w32api, the fact that mingw.org is dw2 and (should, eventually) support a usable gcj/java and Ada implementation, while mingw64 does not appear to support either language -- and its sjlj exception model is slower than dw2, painfully so in java according to reports. OTOH, sjlj is required if you want to unwind exceptions through foreign frames; that is, pass a function to a w32api call as a callback, and allow that callback function to throw. You just can't do that with dw2; your app will crash. So, for (a) -- we get mingw64-32 for "free", but probably want also mingw32.org because it has certain difference that make it more appropriate for some tasks/languages/(legal concerns?). (b) Well, if we're going to have mingw64-32 in some form, we might as well treat it like a "normal" cross compiler where you do --host=the-32bit-variant-I-want instead of --host=64bit-mingw-compiler + CFLAGS="-m32". However, that argument holds for both a "single-lib" 32bit gcc based on mingw64, and for this option (b) multilib beast. Consensus, however, appears to be turning against a default-to-32-bit, *multilib capable*, mingw64 gcc, no matter what ELSE is part of the cygwin milieu. (c) Again, if the 64bit mingw64 gcc is multilib, then the mingw64-32 stuff is going to be present. We might as well also have a "dedicated" mingw64 gcc focused specifically on that subtarget, since --host=i686-w64-mingw32 would confuse fewer of our users than --host=x86_64-w64-mingw32 CFLAGS="-m32". ("What? I don't have a 64bit machine! Whine, groan, grumble...") The argument for ALSO providing a mingw.org 32bit compiler, when we already have a mingw64 32bit compiler, presented above still hold: the mingw.org compiler has certain differences that may make it a more appropriate choice for certain tasks/languages/(legal concerns?). --- Now, if we overrule the mingw64 people (and Yaakov), and say "No, thou shalt not provide a multilib compiler, not even your 64bit compiler", then there is less reason to worry about mingw64-32. In that case, we could have a 64bit (only) compiler based on mingw64, and a 32bit (only) compiler based on mingw.org. The downside of this is, that's not what the mingw64 *people* appear to want to give us. We usually grant a large amount of deference to the people actually doing the work. Also, it'd be nice to be able to compare and contrast the two cross compilers in operation on cygwin...how else could we test whether cygwin is compilable with mingw64's w32api (*and* startup objects, since those appear to be different? Does that matter for cygwin-1.dll?) > - Along the same lines, what are the advantages of having two sets of > Windows headers and three sets of libs and DLLs? I think I may have hit most of that, above, but: * only mingw64's version is 64bit clean. If you want the 64bit compiler, you have to have the 64bit-compatible mingw-runtime and w32api (ne' "crt" and "headers"). So that's one of the copies. And, if the 64bit compiler is multilib, then you have to also have the "32bit" flavor of mingw64's libs/DLLs/headers anyway -- and that's two copies. * mingw64's w32api files are more complete, even for 32bit. So...that's a definite plus. But, the choice of using mingw64's w32api and mingw-runtime (e.g. "crt" and "headers") also implies a different ABI: sjlj vs. dw2, and different startup objects, etc. AND it implies -- at least for the moment -- a lack of support for mingw gcj and Ada. So there are pluses and minuses here. * mingw.org: Well, wh
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 > 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
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 7, 2010 at 6:12 PM, 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": > > (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 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 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 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. It uses the Cygwin gcc either natively or as a cross-compiler. cgf
Re: gcc4: next release
On 7/7/2010 11:12 AM, Corinna Vinschen wrote: The important question for me is, can Cygwin be built using the w32api based on the mingw64 sources? Is it possible? Maybe; we'll just have to try it. Is it legally permissible, given (possibly overblown?) concerns about provenance of the changes to mingw64's w32api headers and libs? Dunno. See my earlier message [1], and ask a Red Hat lawyer. [1] http://cygwin.com/ml/cygwin-apps/2010-07/msg00081.html -- Chuck
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
On 7/7/2010 9:48 AM, Corinna Vinschen wrote: On Jul 7 08:58, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* sysroot idea. However, I don't like the idea in the least to keep two different versions of w32api around. It's one target, so we should have one set of headers only. Right? Wrong? None of that? Unfortunately, it sounds like we've stepped into the middle of a dispute between the mingw folks and the mingw64 folks. Well, yes. But not one in which third parties like cygwin would take direct fire. And efforts are underway to enable closer cooperation, at least, between the two teams. I don't think the projects will ever merge, and I think...that might be a good thing. The extra diversity -- so long as both teams continue to push fixes upstream -- should help make the gcc code better for PE/COFF all around, and that helps cygwin, too. Maybe the best thing for us to do would be to decide to use only one or the other but not both. I think both teams would prefer if both toolchains were available on cygwin -- provided we @ cygwin have sufficient volunteers to handle the job(s). Is Dave K + JonY enough? I know I would prefer to see both, and not have cygwin pick one or the other. More on that, in a different message. Hmm, sounds bad. I would love to have a 64 bit gcc in the distro. From my POV, the only reason not to use mingw64 would be, if the w32api has been changed to 64 bit cleanness at the expense of 32 bit cleanness. Well, there are three "parts" to the compiler and support packages (not counting binutils etc). Using the mingw.org and cygwin names: gcc itself w32api mingw-runtime These are called, in mingw64 land, gcc crt (contains the libs for both "mingw-runtime" and "w32api") headers (contains the include files for both "mingw runtime" and "w32api") The mingw-runtime bits differ between the two projects as JonY has described elsewhere. The gcc bits for the two projects are all basically pushed upstream (there may be a few local patches, but those are probably minor). So, you just choose a different --target when building gcc and you can get mingw64 or mingw.org version. JonY also described how the w32api bits differ, from a technical standpoint. However, what JonY didn't mention was the w32api difference that actually was the root cause of the fork: licensing and provenance. (Later, personality issues widened the breach, and then technical decisions pushed things even farther apart. The personality issues, I hope, are on their way to being mended. Technical issues can be resolved. But the licensing...I dunno. And cygwin should probably care about that, *especially* with regards to the w32api headers and libs used to build cygwin itself). Here's the deal, as I understand it: (1) mingw32's (and cygwin's) w32api is under some custom license dreamed up by Anders Norlander, which is very MIT/X-ish, but isn't identical. And it is not, contrary to rumor, public domain. The mingw team is trying to contact Anders, to get that license revised to either (a) public domain, with a fallback to some other license in those jurisdictions that do not recognize public domain, or (b) actual MIT/X. But that's a side issue to this discussion (important, to be sure, but save that for later). For more info, see http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3985 and thread, as well as http://thread.gmane.org/gmane.comp.gnu.mingw.user/33519/focus=33537 and the subthread branching off of that message. (2) mingw32's (and cygwin's) mingw-runtime is public domain. This may be problematic in some jurisdictions (especially some EU countries) that do not recognized pd -- which is one reason the 'relicensing' discussion came up and is on-going. (3) Now, given these issues, especially the pd "problem", mingw64's crt+headers (which combine and extend elements that fall under cygwin's w32api AND mingw-runtime categories), are provided under an EITHER/OR arrangement: according to the lawyers at Kai's company who looked in to this, the licensing/disclaimer text boils down to: copyright is disclaimed and it is public domain, UNLESS the legal jurisdiction doesn't recognize the concept -- in which case copyright is asserted and the files are available under the ZPL (a very permissive, non-copyleft but GPL-compatible license). I don't *really* understand how all that works, 'cause IANAL, but...it's all kosher according to Kai's legal beagles. And, given all that, then (IM-not-a-laywer-O) mingw.org can freely snarf, under public domain, anything in mingw64 so long as they do so in a jurisdiction that recognizes such -- there's no legal impediment to mingw.org incorporating a lot of mingw64's stuff. IF...mingw.org is confident that the contents of mingw64 truly ARE legally public domain. And that's the rub, and the
Re: gcc4: next release (Dave Korn we need you)
On Wed, Jul 7, 2010 at 12:53 PM, Christopher Faylor 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 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, 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 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
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. 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. Yaakov
Re: gcc4: next release
On Jul 7 10:49, Christopher Faylor wrote: > On Wed, Jul 07, 2010 at 04:43:49PM +0200, Corinna Vinschen wrote: > >Ok, that's something I can live with. I don't understand the notion to > >keep _WIN32_WINNT at 0x0400 anyway. The idea of this value is to be set > >manually if I *don't* want modern functions, but the default should be > >to allow *all* function so it should be at least set to 0x0601 at > >present. I don't see why using w32api should be different from using > >recent MS headers. But, never mind, that's not the point of this > >thread. > > It sorta is if we decide to just go with the mingw64 stuff. The important question for me is, can Cygwin be built using the w32api based on the mingw64 sources? > I agree with your observations though. Both projects seem to think that using the LCD is the way to go, unfortunately. It's just a different one. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
On Wed, Jul 07, 2010 at 04:43:49PM +0200, Corinna Vinschen wrote: >Ok, that's something I can live with. I don't understand the notion to >keep _WIN32_WINNT at 0x0400 anyway. The idea of this value is to be set >manually if I *don't* want modern functions, but the default should be >to allow *all* function so it should be at least set to 0x0601 at >present. I don't see why using w32api should be different from using >recent MS headers. But, never mind, that's not the point of this >thread. It sorta is if we decide to just go with the mingw64 stuff. I agree with your observations though. cgf
Re: gcc4: next release
On Jul 7 22:04, JonY wrote: > On 7/7/2010 21:59, Corinna Vinschen wrote: > >On Jul 7 21:19, JonY wrote: > >>On 7/7/2010 20:58, Christopher Faylor wrote: > >>>On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: > Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* > sysroot idea. However, I don't like the idea in the least to keep > two different versions of w32api around. It's one target, so we should > have one set of headers only. Right? Wrong? None of that? > >>> > >>>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. > >>> > >>>cgf > >>> > >> > >>Here are some of the technical issues. > >>[...] > >>As for mingw-w64 headers API, it does not support anything lower > >>than XP, Win2K is not supported, different from mingw.org's Win9X > >>compatibility. > > > >How do you do that? The XP functionality is a superset of the W2K > >functionality, which in turn is a superset of the NT4 functionality. > >So, in theory, headers supporting XP should support any earlier > >system(*). > > > > > >Corinna > > > >(*) Note that I ignore 95/98/Me deliberately since they deserve to be > > forgotten. > > > > > Hi, > > _WIN32_WINNT by default is set to 0x501, there are no ifdef guards > for anything lower. So if you wanted to limit yourself to win2k > functionality, there isn't a practical way to do it other than > looking up MSDN. Ok, that's something I can live with. I don't understand the notion to keep _WIN32_WINNT at 0x0400 anyway. The idea of this value is to be set manually if I *don't* want modern functions, but the default should be to allow *all* function so it should be at least set to 0x0601 at present. I don't see why using w32api should be different from using recent MS headers. But, never mind, that's not the point of this thread. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
On 7/7/2010 21:59, Corinna Vinschen wrote: On Jul 7 21:19, JonY wrote: On 7/7/2010 20:58, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* sysroot idea. However, I don't like the idea in the least to keep two different versions of w32api around. It's one target, so we should have one set of headers only. Right? Wrong? None of that? 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. cgf Here are some of the technical issues. [...] As for mingw-w64 headers API, it does not support anything lower than XP, Win2K is not supported, different from mingw.org's Win9X compatibility. How do you do that? The XP functionality is a superset of the W2K functionality, which in turn is a superset of the NT4 functionality. So, in theory, headers supporting XP should support any earlier system(*). Corinna (*) Note that I ignore 95/98/Me deliberately since they deserve to be forgotten. Hi, _WIN32_WINNT by default is set to 0x501, there are no ifdef guards for anything lower. So if you wanted to limit yourself to win2k functionality, there isn't a practical way to do it other than looking up MSDN. So while it may work on win2k, but if you do accidentally use XP specific functionality like some of newer network API functions, your program crashes on win2K.
Re: gcc4: next release
2010/7/7 Corinna Vinschen : > On Jul 7 21:19, JonY wrote: >> On 7/7/2010 20:58, Christopher Faylor wrote: >> >On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: >> >>Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* >> >>sysroot idea. However, I don't like the idea in the least to keep >> >>two different versions of w32api around. It's one target, so we should >> >>have one set of headers only. Right? Wrong? None of that? >> > >> >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. >> > >> >cgf >> > >> >> Here are some of the technical issues. >> [...] >> As for mingw-w64 headers API, it does not support anything lower >> than XP, Win2K is not supported, different from mingw.org's Win9X >> compatibility. > > How do you do that? The XP functionality is a superset of the W2K > functionality, which in turn is a superset of the NT4 functionality. > So, in theory, headers supporting XP should support any earlier > system(*). To clarify this point. It is in fact possible to build NT4/Windows 2000 32-bit applications by mingw-w64 header-set and runtime, too. We default to XP as default windows version. For windows OSes older then XP, we don't provide active support (until now - obviously for 64-bit OS has to be XP or newer). > > Corinna > > (*) Note that I ignore 95/98/Me deliberately since they deserve to be > forgotten. Agreed ;) Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination
Re: gcc4: next release
On Jul 7 21:19, JonY wrote: > On 7/7/2010 20:58, Christopher Faylor wrote: > >On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: > >>Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* > >>sysroot idea. However, I don't like the idea in the least to keep > >>two different versions of w32api around. It's one target, so we should > >>have one set of headers only. Right? Wrong? None of that? > > > >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. > > > >cgf > > > > Here are some of the technical issues. > [...] > As for mingw-w64 headers API, it does not support anything lower > than XP, Win2K is not supported, different from mingw.org's Win9X > compatibility. How do you do that? The XP functionality is a superset of the W2K functionality, which in turn is a superset of the NT4 functionality. So, in theory, headers supporting XP should support any earlier system(*). Corinna (*) Note that I ignore 95/98/Me deliberately since they deserve to be forgotten. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
On Jul 7 08:58, Christopher Faylor wrote: > On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: > >Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* > >sysroot idea. However, I don't like the idea in the least to keep > >two different versions of w32api around. It's one target, so we should > >have one set of headers only. Right? Wrong? None of that? > > 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. Hmm, sounds bad. I would love to have a 64 bit gcc in the distro. From my POV, the only reason not to use mingw64 would be, if the w32api has been changed to 64 bit cleanness at the expense of 32 bit cleanness. But I certainly won't interfere in a dispute between two communities I'm not part of. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
On 7/7/2010 20:58, Christopher Faylor wrote: On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* sysroot idea. However, I don't like the idea in the least to keep two different versions of w32api around. It's one target, so we should have one set of headers only. Right? Wrong? None of that? 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. cgf Here are some of the technical issues. The C startup ABI between the 2 is also different enough that linking from one compiler to another isn't recommended, though I haven't tried recently. This is also true for C++, where mingw.org preference to dw2, but mingw-w64 uses sjlj for both 32bit and 64bit. As for mingw-w64 headers API, it does not support anything lower than XP, Win2K is not supported, different from mingw.org's Win9X compatibility. Compiler feature wise is also different, hence the "w64" vendor key to turn on some of GCC's features, especially the unicode C startup. mingw-w64 is relatively new compared to mingw.org's history, so obviously the latter has a much larger user base. For compatibility purposes, if we do have mingw-w64 toolchain, there should also be a separate toolchain for mingw.org, if we don't want to get bombarded with "Why does the new MinGW GCC not work?" questions.
Re: gcc4: next release
On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: >Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* >sysroot idea. However, I don't like the idea in the least to keep >two different versions of w32api around. It's one target, so we should >have one set of headers only. Right? Wrong? None of that? 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. cgf
Re: gcc4: next release
On Jul 7 08:08, Charles Wilson wrote: > [accidentally posted to the main list; re-sent here] > > On 7/6/2010 10:35 PM, Yaakov (Cygwin/X) wrote: > > On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote: > >> I'd want to check with Corinna on this but I am mildly opposed to putting > >> this in /opt. I don't think it makes sense there. But I haven't been > >> following closely, though. Where does Debian put these packages? > > AFAICT, debian (like fedora) put them in /usr. However, neither debian > nor fedora gcc-mingw32 packages include any documentation (like info > files or man pages) -- presumably because such docu might collide with > those provided by the system gcc. (Well, fedora appears to include the > man pages, but they get renamed as $target-foo.1; debian doesn't provide > any) > > Furthermore, neither debian nor fedora provide any i18n message > catalogs. Whether that is because the cross compiler is compiled with > --disable-nls, or it is just assumed that the system compiler and the > mingw32 cross compiler will always and forever be kept in sync, it > doesn't matter: the i18n files just plain aren't present. (BOTH > "solutions" appear to be the case for fedora). > [...snip a lot of info...] > Note that the "official sysroot" idea can be used with any of these > three options -- and might be a good thing to establish, on its own merits: > >/usr/sysroot/mingw32/* >/usr/sysroot/mingw64/* >/usr/sysroot/mingw64-32/* > > I hope I have summed up the various competing proposals fairly, and that > this edition of my patented War and Peace emails helps move the > discussion along to a conclusion. Ok, I'm sufficiently confused now. So, here are a few questions. - Why do we need two different mingw's again? What are the merits of having mingw32 *and* mingw64-32? - Along the same lines, what are the advantages of having two sets of Windows headers and three sets of libs and DLLs? - Where are the differences of w32api from mingw32 and w32api from the mingw64 project? One of them is apparently that the mingw64 headers are 64 bit clean. What else? - Last but not least, why don't the projects merge and only keep one set of w32api headers and libs? After all, they have the same development target. A merge would help everyone, afaics. Having said that, I can't see why keeping mingw32 would have any real advantage, except that it's part of the winsup build tree, so we get the headers and libs for free when building Cygwin. Other than that, switching to mingw64 only seem to have advantages, given that it gives us the first gcc targeting 64 bit Windows as well, so there's a real chance to create a 64 bit Cygwin in the next 10 years. Can anybody enlighten me? Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* sysroot idea. However, I don't like the idea in the least to keep two different versions of w32api around. It's one target, so we should have one set of headers only. Right? Wrong? None of that? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
[accidentally posted to the main list; re-sent here] On 7/6/2010 10:35 PM, Yaakov (Cygwin/X) wrote: > On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote: >> I'd want to check with Corinna on this but I am mildly opposed to putting >> this in /opt. I don't think it makes sense there. But I haven't been >> following closely, though. Where does Debian put these packages? AFAICT, debian (like fedora) put them in /usr. However, neither debian nor fedora gcc-mingw32 packages include any documentation (like info files or man pages) -- presumably because such docu might collide with those provided by the system gcc. (Well, fedora appears to include the man pages, but they get renamed as $target-foo.1; debian doesn't provide any) Furthermore, neither debian nor fedora provide any i18n message catalogs. Whether that is because the cross compiler is compiled with --disable-nls, or it is just assumed that the system compiler and the mingw32 cross compiler will always and forever be kept in sync, it doesn't matter: the i18n files just plain aren't present. (BOTH "solutions" appear to be the case for fedora). As a side note, it seems that *fedora* is configuring with --target=i686-pc-mingw32, which is (effectively) the mingw.org compiler (minus some custom mingw.org patches, but plus some fedora-specific ones to keep mingw32-gcc and system gcc coordinated). It seems that this implies that "fedora mingw32" is 32bit only; it doesn't support 64bit at all (--disable-multilib). OTOH, debian uses has two different target triples for their combo mingw cross compiler package. It appears to NOT be multilib; simply two separate cross compilers combined into the same installation package: one for 'i586-mingw32msvc' and one for 'amd64-mingw32msvc' -- whatever THAT means. Obviously some sort of mapping is going on under the hood -- but whether it maps to the "mingw.org-ish" i586-pc-mingw32 or to the "mingw64-ish" x86_64-w64-mingw32 I don't know. Maybe i586-mingw32msvc maps to i586-pc-mingw32 for a mingw.org cross compiler, and md64-mingw32msvc maps to x86_64-w64-mingw32 for a mingw64 cross compiler, and both are simply mushed together... So, to sum up: it seems that the linuxes avoid the issue in two ways: 1) don't ship documentation that would clash with the system compiler http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543393 2) (fedora) compile using --disable-nls, so that locale/* clashing is a non-issue, or (debian) or simply remove the clashing files from the installation tree, and assume cross compiler will use the i18n files from the system gcc: + # remove some non-cross stuff that will clash with other packages + # and shuffle things about as required. + rm -rf debian/$(package)/usr/include + rm -rf debian/$(package)/usr/info + rm -rf debian/$(package)/usr/share/locale + rm debian/$(package)/usr/lib/*a + rm -rf debian/$(package)/usr/share/man/man7 Both appear to make some assumptions (explicit, wrt to i18n files in the case of debian; implicit, with respect to user documentation, for both fedora and debian) that the system gcc and the mingw cross compiler will be of exactly the same version. (Otherwise, the poor user will be horribly confused, if 'info gcc' talks about the system gcc 4.4.1 which doesn't actually match the mingw-gcc 4.6.0 or whatever. > I'm working with JonY on this as well. If DaveK splits out the info and > l10n into a separate gcc4-common package when he updates to 4.5.x (or > 4.6 trunk), then JonY can package a similar version for mingw64 and > depend on that to provide those files. That, together with one other > fix, should allow mingw64 to go into /usr. > > The only requirement will be coordinating releases (at least the same > major.minor) so that l10n will work for mingw64 as well without worrying > about these collisions. The alternative is to simply --disable-nls but > IMO that is less than optimal. There are two problems with regards to conflicting files, if everything goes into the same $prefix: i18n data and documentation. This applies to gcc. There are additional problems with regards to cross-binutils (libiberty.a, libbfd.a, libopcodes.a; are any of the installed bfd headers "customized" per-target? I dunno.); other than renaming the cross versions 'mingw64-libiberty.a' or perhaps moving these files to an official sysroot "tree for cross-compiled stuff", I don't see a clean way of dealing with this -- although, as I look at JonY's mingw64-binutils package, I don't see these libraries at all!). There are three solutions (for gcc, if not binutils): 1) Keep the mingw64, mingw.org, and cygwin compilers always at the same version. Split the conflicting files into a separate subpackage, provided by (e.g) the cygwin 'version', so that they can be installed independently of any of the actual compilers themselves. This is Yaakov's suggestion. Advantages: more 'cygwinish': all apps in /usr/bin. Simpler.
Re: gcc4: next release
On Jul 6 21:35, Yaakov S wrote: > On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote: > > I'd want to check with Corinna on this but I am mildly opposed to putting > > this in /opt. I don't think it makes sense there. But I haven't been > > following closely, though. Where does Debian put these packages? > > I'm working with JonY on this as well. If DaveK splits out the info and > l10n into a separate gcc4-common package when he updates to 4.5.x (or > 4.6 trunk), then JonY can package a similar version for mingw64 and > depend on that to provide those files. That, together with one other > fix, should allow mingw64 to go into /usr. > > The only requirement will be coordinating releases (at least the same > major.minor) so that l10n will work for mingw64 as well without worrying > about these collisions. The alternative is to simply --disable-nls but > IMO that is less than optimal. The problem is, where's Dave? His input would be quite important, but I didn't see a mail from him for almost a month. Dave? You out there? Just busy, I hope? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: gcc4: next release
On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote: > I'd want to check with Corinna on this but I am mildly opposed to putting > this in /opt. I don't think it makes sense there. But I haven't been > following closely, though. Where does Debian put these packages? I'm working with JonY on this as well. If DaveK splits out the info and l10n into a separate gcc4-common package when he updates to 4.5.x (or 4.6 trunk), then JonY can package a similar version for mingw64 and depend on that to provide those files. That, together with one other fix, should allow mingw64 to go into /usr. The only requirement will be coordinating releases (at least the same major.minor) so that l10n will work for mingw64 as well without worrying about these collisions. The alternative is to simply --disable-nls but IMO that is less than optimal. Yaakov
Re: gcc4: next release
On Wed, Jul 07, 2010 at 09:47:20AM +0800, JonY wrote: >Hello, > >Can I ask what will be the next version of GCC be in Cygwin? > >I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything >cygwin gets installed to /usr, however, with gcc 4.6, the locales data >clashes. > >Charles suggested installing to /opt/mingw64, this doesn't fit well with >the cygwin model, but no clashes there. This allows mingw-w64 GCC >version to be independent of Cygwin's. I'd want to check with Corinna on this but I am mildly opposed to putting this in /opt. I don't think it makes sense there. But I haven't been following closely, though. Where does Debian put these packages? cgf
gcc4: next release
Hello, Can I ask what will be the next version of GCC be in Cygwin? I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything cygwin gets installed to /usr, however, with gcc 4.6, the locales data clashes. Charles suggested installing to /opt/mingw64, this doesn't fit well with the cygwin model, but no clashes there. This allows mingw-w64 GCC version to be independent of Cygwin's. Yaakov suggested installing to /usr, but there are some problems with it. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Locale data is also conflicting. Yaakov suggested that I sync up with Cygwin GCC so the clash won't be so problematic, eg 4.5.0 Cygwin with 4.5.1 branch snapshot for mingw-w64. GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying to avoid breaking user's self-built packages, so 4.5.0 and earlier is out of the question. The current 4.3.4 is too old for mingw-w64. I'll be absent for about a week starting tomorrow, so no need to hurry in replying.