Re: [RFU] libogg-1.2.0-1
On Jul 6 10:24, David Rothenberger wrote: Please delete 1.1.3-1 and leave 1.1.4-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/libogg0-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/libogg-devel-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.2.0-1-src.tar.bz2 Uploaded and 1.1.3-1 removed. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] libvorbis-1.3.1-1
On Jul 6 10:41, David Rothenberger wrote: Please remove 1.2.0-2 and leave 1.2.3-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisfile3/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisfile3/libvorbisfile3-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisenc2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisenc2/libvorbisenc2-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis0/libvorbis0-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-devel/libvorbis-devel-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-1.3.1-1-src.tar.bz2 Uploaded and 1.2.0-2 removed. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] libao-1.0.0-1
On Jul 6 10:59, David Rothenberger wrote: Please leave 0.8.8-1 as previous. The new version introduces libao4, so please move the libao2 package to the _obsolete category. Done. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao4/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao4/libao4-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-devel/libao-devel-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-1.0.0-1-src.tar.bz2 \ Uploaded. Thanks, 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 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: [ITP] libkate - Karaoke codec
On Jul 6 15:41, David Rothenberger wrote: On 7/6/2010 2:55 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-07-06 at 11:19 -0700, David Rothenberger wrote: I'd like to package libkate[1] in preparation for packaging the newest version of vorbis-tools. libkate is included in Fedora[2]. Looks good to me. FYI, instead of the custom src_install() to remove KateDJ, you could define the following after *_CONTENTS: PKG_IGNORE=usr/bin/KateDJ usr/lib/python*/ usr/share/man/man1/KateDJ* Thanks for the tip. So, is that ok to upload or are you going to change that first? 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. cygport happier.
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
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 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 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 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
2010/7/7 Corinna Vinschen corinna-cyg...@cygwin.com: 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 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
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: [ITP] libkate - Karaoke codec
On Wed, 2010-07-07 at 10:19 +0200, Corinna Vinschen wrote: So, is that ok to upload or are you going to change that first? It's not wrong, just cleaner for the maintainer, that's all. Yaakov
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 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: [ITP] libkate - Karaoke codec
On Jul 7 09:44, Yaakov S wrote: On Wed, 2010-07-07 at 10:19 +0200, Corinna Vinschen wrote: So, is that ok to upload or are you going to change that first? It's not wrong, just cleaner for the maintainer, that's all. Thanks, yes, that's how I understood it. I'm just asking if David wants to change that first to use your suggestion or if he wants the package to be uploaded as is. 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, 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 (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: [ITP] libkate - Karaoke codec
On 7/7/2010 1:19 AM, Corinna Vinschen wrote: On Jul 6 15:41, David Rothenberger wrote: On 7/6/2010 2:55 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-07-06 at 11:19 -0700, David Rothenberger wrote: I'd like to package libkate[1] in preparation for packaging the newest version of vorbis-tools. libkate is included in Fedora[2]. Looks good to me. FYI, instead of the custom src_install() to remove KateDJ, you could define the following after *_CONTENTS: PKG_IGNORE=usr/bin/KateDJ usr/lib/python*/ usr/share/man/man1/KateDJ* Thanks for the tip. So, is that ok to upload or are you going to change that first? I've made the change and updated the packages. They're now ready for upload. Thanks for asking. -- David Rothenberger daver...@acm.org Jenkinson's Law: It won't work.
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: [ITP] libkate - Karaoke codec
On Jul 7 08:34, David Rothenberger wrote: On 7/7/2010 1:19 AM, Corinna Vinschen wrote: On Jul 6 15:41, David Rothenberger wrote: On 7/6/2010 2:55 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-07-06 at 11:19 -0700, David Rothenberger wrote: I'd like to package libkate[1] in preparation for packaging the newest version of vorbis-tools. libkate is included in Fedora[2]. Looks good to me. FYI, instead of the custom src_install() to remove KateDJ, you could define the following after *_CONTENTS: PKG_IGNORE=usr/bin/KateDJ usr/lib/python*/ usr/share/man/man1/KateDJ* Thanks for the tip. So, is that ok to upload or are you going to change that first? I've made the change and updated the packages. They're now ready for upload. Thanks for asking. Uploaded. Thanks, 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 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
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 root of
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 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 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
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, why bother with these files any longer, even if we
