Re: [RFU] mingw-w64
Hi Jon, On Jul 1 01:08, JonY wrote: Hi, Here are the new builds, please remove the oldest versions from each category, thanks. may I ask you a favor? It would be really helpful if you could add a statement what versions exactly to remove, perhaps even in the form of an easy `rm' command. Otherwise the uploader has to figure this out one directory after the other, which is kind of arduous, given that almost all packages have another version number. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn5134-1-src.tar.bz2 [...] Uploaded, old versions not removed yet. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On 7/2/2012 17:22, Corinna Vinschen wrote: Hi Jon, On Jul 1 01:08, JonY wrote: Hi, Here are the new builds, please remove the oldest versions from each category, thanks. may I ask you a favor? It would be really helpful if you could add a statement what versions exactly to remove, perhaps even in the form of an easy `rm' command. Otherwise the uploader has to figure this out one directory after the other, which is kind of arduous, given that almost all packages have another version number. OK, Will this suffice? find mingw64-i686/mingw64-i686-gcc -name *4.5.3-2* | xargs rm find mingw64-i686/mingw64-i686-binutils -name *2.21.53-1* | xargs rm find mingw64-i686/mingw64-i686-headers -name *svn4430-1* | xargs rm find mingw64-i686/mingw64-i686-runtime -name *svn4430-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-binutils -name *2.21.53-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-gcc -name *4.5.3-2* | xargs rm find mingw64-x86_64/mingw64-x86_64-headers -name *svn4430-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-runtime -name *svn4430-1* | xargs rm signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On Jul 2 17:43, JonY wrote: On 7/2/2012 17:22, Corinna Vinschen wrote: Hi Jon, On Jul 1 01:08, JonY wrote: Hi, Here are the new builds, please remove the oldest versions from each category, thanks. may I ask you a favor? It would be really helpful if you could add a statement what versions exactly to remove, perhaps even in the form of an easy `rm' command. Otherwise the uploader has to figure this out one directory after the other, which is kind of arduous, given that almost all packages have another version number. OK, Will this suffice? find mingw64-i686/mingw64-i686-gcc -name *4.5.3-2* | xargs rm find mingw64-i686/mingw64-i686-binutils -name *2.21.53-1* | xargs rm find mingw64-i686/mingw64-i686-headers -name *svn4430-1* | xargs rm find mingw64-i686/mingw64-i686-runtime -name *svn4430-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-binutils -name *2.21.53-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-gcc -name *4.5.3-2* | xargs rm find mingw64-x86_64/mingw64-x86_64-headers -name *svn4430-1* | xargs rm find mingw64-x86_64/mingw64-x86_64-runtime -name *svn4430-1* | xargs rm Excellent! Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On Sun, Mar 18, 2012 at 10:06:24PM +0800, JonY wrote: Btw, do I need to submit an announce message for each package? No, you don't need to send a separate announcement for each package. Some announcements tend to disappear. Actualy, it's more likely that some senders of email tend to ignore bounce messages.
Re: [RFU] mingw-w64
On Sun, Mar 18, 2012 at 10:12:08AM -0400, Christopher Faylor wrote: On Sun, Mar 18, 2012 at 10:06:24PM +0800, JonY wrote: Btw, do I need to submit an announce message for each package? No, you don't need to send a separate announcement for each package. Some announcements tend to disappear. Actualy, it's more likely that some senders of email tend to ignore bounce messages. Actually and Uploaded. I haven't deleted the oldest version yet though. cgf
Re: [RFU] mingw-w64 crt/headers
On Jan 8 08:06, JonY wrote: Hi, there was a bug that caused GCC to spill spurious warnings about printf formats. This release fixes it. http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4725-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4725-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4725-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4725-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4725-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4725-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/setup.hint http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4725-1-src.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4725-1.tar.bz2 http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/setup.hint Leave the previous versions, previous GCC still require them. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On Dec 19 21:24, JonY wrote: On 12/19/2011 08:42, Charles Wilson wrote: On 12/17/2011 11:35 PM, JonY wrote: New mingw-w64 build is ready. Remove the oldest in each category, leave pthreads. A user requested a recent bugfix to be propagated. Sorry for the inconvenience, can you remove the recently uploaded headers and crt? Use the following, thanks. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/setup.hint Uploaded and 3.0b_svn4679-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] mingw-w64
Hi, Here's the fixed binutils for i686 mingw-w64. Well, at least it is confirmed to be working on my machine. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-binutils/mingw64-i686-binutils-2.22.51-2-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-binutils/mingw64-i686-binutils-2.22.51-2.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-binutils/setup.hint Please remove the broken 2.22.51-1, thanks. x86_64 version seems to be fine on my machine. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On Dec 20 19:45, JonY wrote: Hi, Here's the fixed binutils for i686 mingw-w64. Well, at least it is confirmed to be working on my machine. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-binutils/mingw64-i686-binutils-2.22.51-2-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-binutils/mingw64-i686-binutils-2.22.51-2.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-binutils/setup.hint Please remove the broken 2.22.51-1, thanks. x86_64 version seems to be fine on my machine. Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On 12/19/2011 08:42, Charles Wilson wrote: On 12/17/2011 11:35 PM, JonY wrote: New mingw-w64 build is ready. Remove the oldest in each category, leave pthreads. A user requested a recent bugfix to be propagated. Sorry for the inconvenience, can you remove the recently uploaded headers and crt? Use the following, thanks. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/setup.hint signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On 12/19/2011 05:12, Cary R. wrote: Hi Jon, It would be very nice if the headers/runtime could be from svn 4683 or later. 4683 fixed a problem regarding SSIZE_MAX that prevents me from cross-compiling Icarus Verilog without performing a manual hack to the code. Since I have a solution I can live with this for now, but a version with this fix would be most appreciated. Regards, Cary Sure, I'll try to get to it soon, update on hold for the moment. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On 12/17/2011 11:35 PM, JonY wrote: New mingw-w64 build is ready. Remove the oldest in each category, leave pthreads. Done. -- Chuck
Re: [RFU] mingw-w64
On Aug 31 15:15, JonY wrote: Hi, Here's a refresh of the mingw-w64. For the headers and runtime, remove 4075 and 4214, for both i686 and x86_64 archs. Please remove the oldest version for the others. Done. Btw., would you mind to restructure your download directories so that they resemble the structure of the Cygwin distro directories? That would reduce the work required to upload your files enormously! BTW, is GCC 4.6 for Cygwin anywhere near? :) 4.5.3 is near, afaik. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On 8/31/2011 17:11, Corinna Vinschen wrote: On Aug 31 15:15, JonY wrote: Hi, Here's a refresh of the mingw-w64. For the headers and runtime, remove 4075 and 4214, for both i686 and x86_64 archs. Please remove the oldest version for the others. Done. Btw., would you mind to restructure your download directories so that they resemble the structure of the Cygwin distro directories? That would reduce the work required to upload your files enormously! OK, sorry about that, I'll do that next time. SF is sadly lacking an FTP interface (why don't they have anonymous read-only sftp?) to make recursive downloading even easier. BTW, is GCC 4.6 for Cygwin anywhere near? :) 4.5.3 is near, afaik. OK, I was wondering how to transition 4.5.x to 4.6.x for mingw-w64 when the time comes, pthreads-win32 will be removed in favor of winpthreads, they're not exactly ABI compatible. Right now, only libgomp is using pthreads-win32. C++ ABI for 4.6.x has also changed for mingw* (including mingw.org) with the introduction of thiscall, not sure if this will affect Cygwin itself. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On 8/31/2011 5:48 AM, JonY wrote: On 8/31/2011 17:11, Corinna Vinschen wrote: On Aug 31 15:15, JonY wrote: BTW, is GCC 4.6 for Cygwin anywhere near? :) 4.5.3 is near, afaik. OK, I was wondering how to transition 4.5.x to 4.6.x for mingw-w64 when the time comes, pthreads-win32 will be removed in favor of winpthreads, they're not exactly ABI compatible. Right now, only libgomp is using pthreads-win32. So, it sounds like mingw64's version of libgomp (for gcc-4.6) will have to bump its DLL number from the current libgomp-1.dll to libgomp-2.dll -- you don't want an existing -fopenmp client, that links to both libgomp-1.dll (which itself depends on pthreadGC2.dll) pthreadGC2.dll to suddenly get surprised by (new) libgomp-1.dll (which depends on winpthreads-0.dll) pthreadGC2.dll because then that existing client would depend on two different pthreads implementations. That's a sure recipe for failure... C++ ABI for 4.6.x has also changed for mingw* (including mingw.org) with the introduction of thiscall, not sure if this will affect Cygwin itself. Hmm. don't know what the correct (mingw[64]) solution for this would be. In the past, when the C++ ABI changed, we didn't bump the libstdc++ DLL number, because so many other things ALSO break (in precompiled C++ clients), that just isolating ONE change via the DLL number of one runtime lib was pointless. I suspect that is true here, too. It probably means a flag day -- all precompiled mingw[org,64] C++ offerings will need to be simultaneously upgraded with the release of the mingw[org,64] 4.6 compiler. (I don't think mingw.org HAS any, so...non-issue). OTOH, the cygwin project DOES provide several precompiled C++ packages, so cygwin will probably need to do a flag day for them (when cygwin-gcc-4.6 is released), but I don't think the cygwin package ITSELF would be affected. -- Chuck
Re: [RFU] mingw-w64
On Aug 31 09:54, Charles Wilson wrote: On 8/31/2011 5:48 AM, JonY wrote: C++ ABI for 4.6.x has also changed for mingw* (including mingw.org) with the introduction of thiscall, not sure if this will affect Cygwin itself. [...] OTOH, the cygwin project DOES provide several precompiled C++ packages, so cygwin will probably need to do a flag day for them (when cygwin-gcc-4.6 is released), but I don't think the cygwin package ITSELF would be affected. I don't think this is necessary, unless __thiscall will become default behaviour in g++. However, I guess this is the responsibility of the gcc maintainer for a given target. For 32 bit Cygwin I would not do it, for 64 bit it might make sense, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On 8/31/2011 22:12, Corinna Vinschen wrote: On Aug 31 09:54, Charles Wilson wrote: On 8/31/2011 5:48 AM, JonY wrote: C++ ABI for 4.6.x has also changed for mingw* (including mingw.org) with the introduction of thiscall, not sure if this will affect Cygwin itself. [...] OTOH, the cygwin project DOES provide several precompiled C++ packages, so cygwin will probably need to do a flag day for them (when cygwin-gcc-4.6 is released), but I don't think the cygwin package ITSELF would be affected. I don't think this is necessary, unless __thiscall will become default behaviour in g++. However, I guess this is the responsibility of the gcc maintainer for a given target. For 32 bit Cygwin I would not do it, for 64 bit it might make sense, though. Corinna I have always thought about mingw* and Cygwin as a tightly coupled target, but good point, __thiscall is meant for better compatibility with MSVC. It wouldn't be a big deal for Cygwin to stay with the current ABI, while mingw* will move to the new default. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On 8/31/2011 21:54, Charles Wilson wrote: On 8/31/2011 5:48 AM, JonY wrote: On 8/31/2011 17:11, Corinna Vinschen wrote: On Aug 31 15:15, JonY wrote: BTW, is GCC 4.6 for Cygwin anywhere near? :) 4.5.3 is near, afaik. OK, I was wondering how to transition 4.5.x to 4.6.x for mingw-w64 when the time comes, pthreads-win32 will be removed in favor of winpthreads, they're not exactly ABI compatible. Right now, only libgomp is using pthreads-win32. So, it sounds like mingw64's version of libgomp (for gcc-4.6) will have to bump its DLL number from the current libgomp-1.dll to libgomp-2.dll -- you don't want an existing -fopenmp client, that links to both libgomp-1.dll (which itself depends on pthreadGC2.dll) pthreadGC2.dll to suddenly get surprised by (new) libgomp-1.dll (which depends on winpthreads-0.dll) pthreadGC2.dll because then that existing client would depend on two different pthreads implementations. That's a sure recipe for failure... Ideally, libgomp should provide proper ABI/API isolation from whatever underlying thread implementation, so a bump on libgomp shouldn't be necessary, but I have yet to test this. Reading the package contributor's guide, there isn't a way to force a mutually exclusive package, eg old pthreads-win32 with devlibs musn't be installed with winpthreads. C++ ABI for 4.6.x has also changed for mingw* (including mingw.org) with the introduction of thiscall, not sure if this will affect Cygwin itself. Hmm. don't know what the correct (mingw[64]) solution for this would be. In the past, when the C++ ABI changed, we didn't bump the libstdc++ DLL number, because so many other things ALSO break (in precompiled C++ clients), that just isolating ONE change via the DLL number of one runtime lib was pointless. I suspect that is true here, too. Not bumping the number would also be problematic for precompiled code using the old ABI, I was thinking the old dll be made available via mingw32-libstdc++-6-compat-1 DLL only package. Of course, talk is easy, implementing it would be another problem, since libstdc++ is so integrated into GCC. signature.asc Description: OpenPGP digital signature
Re: [RFU] mingw-w64
On 8/31/2011 10:08 PM, JonY wrote: On 8/31/2011 21:54, Charles Wilson wrote: On 8/31/2011 5:48 AM, JonY wrote: Hmm. don't know what the correct (mingw[64]) solution for this would be. In the past, when the C++ ABI changed, we didn't bump the libstdc++ DLL number, because so many other things ALSO break (in precompiled C++ clients), that just isolating ONE change via the DLL number of one runtime lib was pointless. I suspect that is true here, too. Not bumping the number would also be problematic for precompiled code using the old ABI, I was thinking the old dll be made available via mingw32-libstdc++-6-compat-1 DLL only package. My point is, the ABI of the underlying C++ runtime library is invariably exposed by the (C++) client DLLs -- unless their interface is pure C. So, if you have a stack of C++ dlls with the following dependency APP.EXE libfoo-1.dll libbar-2.dll libbaz-3.dll libstdc++-6.dll libstdc++-6.dll libbaz-3.dll libstdc++-6.dll libstdc++-6.dll libstdc++-6.dll If you bump the DLL for libstdc++-6.dll (so that old clients can continue to use it, via some -compat package, and the new gcc packages ship libstdc++-7.dll), this will require you to bump the DLL number of ALL of the clients, when they are recompiled to use the new runtime. (And, of course, each of those CLIENT dlls will ALSO have to ship a -compat package to provide the old dll with its old dllnum). If you don't do this for the clients, then your stack will break because some are using libstdc++-7 and some are using libstdc++-6, and their definitions for, say, new[] or std::string are different. Oh, and if you DO bump the DLL numbers of all the clients, then you can't really compile APP.EXE (which depends on all those client DLLs) until you finish recompiling the whole stack (and bumping all their dllnums) anyway... Now, this massive bump-and-compat headache is /technically/ the correct procedure. From a /practical/ standpoint, however, I'll point you here: http://www.cygwin.com/ml/cygwin-apps/2009-03/msg00033.html where you can read Yaakov's rant on changing the DLL number of giant stacks of interdependent DLLs on a single platform, due to a platform specific ABI change, and how horrid it makes life for maintainers ON that platform *forever* after. (Esp. with regards to dlopen() and/or LoadLibrary()) In that discussion, I was on the other side at the time; I've come 'round to Yaakov's view -- which is: sure, if the ABI changes badly enough in the underlying runtime, all the client DLLs will break until recompiled. That's bad, but the alternative is WORSE, so you do a flag day, and publish updated versions of all the known client DLLs at the same time the new runtime is released. As it happens, on cygwin there are (a) so few C++ dlls, and (b) even the ones we have are so rarely used, that we did NOT do a flag day, and yet...nobody noticed. Eventually all the C++ clients were recompiled... The considerations from the POV of mingw[org,64] might be different than from cygwin, of course. Of course, talk is easy, implementing it would be another problem, since libstdc++ is so integrated into GCC. Ack. -- Chuck
Re: [RFU] mingw-w64
On Aug 11 19:16, JonY wrote: Hi, here's the headers and runtime refresh, binutils and gcc should still be good. Keep the older copies. wget http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4373-1.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4373-1-src.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/setup.hint \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4373-1-src.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4373-1.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/setup.hint \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4373-1.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4373-1-src.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/setup.hint \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4373-1-src.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4373-1.tar.bz2 \ http://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/setup.hint Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mingw-w64
On 11 August 2011 12:13, JonY wrote: OK, much thanks, I need to find more time to do a full rebuild next time. Any chance we can get a 4.6.x release when you get around to it? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: [RFU] mingw-w64 updates
On 3/15/2011 11:20 AM, JonY wrote: Here's an update for mingw-w64 packages, see the attached list.txt for wget links. SF should really allow anonymous read-only FTP. Please keep the previous version and remove the others. Done. -- Chuck
