Re: [Mingw-w64-public] End of rubenvb builds
Hi, Sorry for answering that late, I was away a bit and could catch up properly only now. This email is unfortunately a bit long, sorry for that too. On Sun, Jun 23, 2013, Ruben Van Boxem wrote: Hi everyone, I have come to the conclusion that my MinGW-w64 builds bring too little to the table for me to continue maintaining them. I strongly encourage you to use the plethora of toolchains in a multitude of configurations available at mingw-builds. Comparing download numbers they have a much higher visibility, and e.g. their adoption by the Qt Project speaks of their quality. They have succeeded in doing what I missed when I decided to start building GCC, so my effort spent in doing that is now wasted. I may dabble into getting Clang 3.3 to work on Windows, perhaps even with libc++, but I am not promising anything. I'll still linger around here though, don't worry. This is sad to read. As a packager I can only understand, in particular when you say that you will probably continue but not try to be as up-to-date as you've been so far, which you've done remarkably well. I believe no such work is ever wasted work. Remember that a few years ago, GCC for Windows meant mingw.org and lots of issues, starting with building your own toolchain. The current ease of build proves how much work on this has been done by everyone: building, helping, testing, fixing and so on. If I've understood correctly, you're basing your decision partly on the download stats from SF.net and the use of the mingw-builds toolchains by the Qt project. Aaron Seigo had mentionned that the toolchain for the Qt project SDK had to use Dwarf2 EH. He also had a whole liste of *hard* requirements (like having multilib [ which I don't understand since QtCreator would hide it anyway ]). This is a case where having more choice changes a lot of things: most of us don't build multilib toolchains with dwarf2 eh. This choice doesn't change anything to the quality of the toolchains and of the work behind them. As for the download stats, I've been trying to understand them for quite some time now without much luck. I was trying to see which impact the new download page would have. I haven't been able to see a difference. Mingw-builds has around 600 downloads per day, half of it seems to be metadata for the installer. I guess that the installer downloads the metadata file which then tells it which downloads are available (I might be completely wrong). This means that there are 300 new toolchain installations everyday. Close to 10k each month and that's around 30k for three month, until the next minor version comes out. In turn, this means there are at least 30k people installing toolchains themselves. I find this hard to believe: people are too lazy for that. We don't have much data for the downloads. When do they happen during the day, where from in the world, by which User Agent, ... ? For yypkg, I have a separate hosting and a webalizer on it. I lack details but I have some more information than what we get from sf.net. For the first 6 days of July, I got around 900 hits from a wget running on mingw32, i.e. the download client in yypkg and definitely not something else (bots, indexers, pidgins, ...). Due to the way yypkg works, this amounts to 2 to 3 downloads per day (I haven't advertized anything recently). Again, if we sum that over a few weeks, it's hundreds of users. I haven't heard *anything* from them. All I know is that they exist. It feels like looking for the Higgs Boson or black matter. You usually don't hear about users and I'm under the impression that for packagers it's even worse. However there are users; it might be difficult to understand who they are, where they are and how they use the binaries but they definitely exist. I'm not trying to change anyone's mind but I know this has been an open question for a long time now and currently we're probably missing 99% of the answer. PS: adding something to the download page is available to any packager that provides the same amount of information as the other toolchains (copy-paste, replace with your own values); I don't think the page is currently crowded. I'll be spending some time on it again soon. -- Adrien Nader -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
-- Alexpux Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig) воскресенье, 7 июля 2013 г. в 16:31, Adrien Nader написал: Hi, Sorry for answering that late, I was away a bit and could catch up properly only now. This email is unfortunately a bit long, sorry for that too. On Sun, Jun 23, 2013, Ruben Van Boxem wrote: Hi everyone, I have come to the conclusion that my MinGW-w64 builds bring too little to the table for me to continue maintaining them. I strongly encourage you to use the plethora of toolchains in a multitude of configurations available at mingw-builds. Comparing download numbers they have a much higher visibility, and e.g. their adoption by the Qt Project speaks of their quality. They have succeeded in doing what I missed when I decided to start building GCC, so my effort spent in doing that is now wasted. I may dabble into getting Clang 3.3 to work on Windows, perhaps even with libc++, but I am not promising anything. I'll still linger around here though, don't worry. This is sad to read. As a packager I can only understand, in particular when you say that you will probably continue but not try to be as up-to-date as you've been so far, which you've done remarkably well. I believe no such work is ever wasted work. Remember that a few years ago, GCC for Windows meant mingw.org and lots of issues, starting with building your own toolchain. The current ease of build proves how much work on this has been done by everyone: building, helping, testing, fixing and so on. If I've understood correctly, you're basing your decision partly on the download stats from SF.net and the use of the mingw-builds toolchains by the Qt project. Aaron Seigo had mentionned that the toolchain for the Qt project SDK had to use Dwarf2 EH. He also had a whole liste of *hard* requirements (like having multilib [ which I don't understand since QtCreator would hide it anyway ]). This is a case where having more choice changes a lot of things: most of us don't build multilib toolchains with dwarf2 eh. This choice doesn't change anything to the quality of the toolchains and of the work behind them. Mingw-builds doesn't build multilib Dwarf toolchains. We build only Sjlj toolchains as multilib. And now Qt use our nomultilib toolchains. As for the download stats, I've been trying to understand them for quite some time now without much luck. I was trying to see which impact the new download page would have. I haven't been able to see a difference. Mingw-builds has around 600 downloads per day, half of it seems to be metadata for the installer. I guess that the installer downloads the metadata file which then tells it which downloads are available (I might be completely wrong). This means that there are 300 new toolchain installations everyday. Close to 10k each month and that's around 30k for three month, until the next minor version comes out. In turn, this means there are at least 30k people installing toolchains themselves. I find this hard to believe: people are too lazy for that. We don't have much data for the downloads. When do they happen during the day, where from in the world, by which User Agent, ... ? For yypkg, I have a separate hosting and a webalizer on it. I lack details but I have some more information than what we get from sf.net. For the first 6 days of July, I got around 900 hits from a wget running on mingw32, i.e. the download client in yypkg and definitely not something else (bots, indexers, pidgins, ...). Due to the way yypkg works, this amounts to 2 to 3 downloads per day (I haven't advertized anything recently). Again, if we sum that over a few weeks, it's hundreds of users. I haven't heard *anything* from them. All I know is that they exist. It feels like looking for the Higgs Boson or black matter. You usually don't hear about users and I'm under the impression that for packagers it's even worse. However there are users; it might be difficult to understand who they are, where they are and how they use the binaries but they definitely exist. I'm not trying to change anyone's mind but I know this has been an open question for a long time now and currently we're probably missing 99% of the answer. PS: adding something to the download page is available to any packager that provides the same amount of information as the other toolchains (copy-paste, replace with your own values); I don't think the page is currently crowded. I'll be spending some time on it again soon. -- Adrien Nader -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net
[Mingw-w64-public] Some DLL-related issues remain
Hi All This email may best addressed by rubenvb, but any resolution is definitely welcome... I am trying to setup for emscripten, and thus need to setup llvm/clang. I am doing this on a netbook with Windows 7 Starter Edition, a 32 bit OS with an Atom processor. I have tried following the setup according to Emscripten Tutorial ( https://github.com/kripken/emscripten/wiki/Tutorial) and the page it refers to Using Emscripten on Windows ( https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows). I initially tried using the files x86_64-w64-mingw32-gcc-4.6.3-2-release-win64_rubenvb.7z x86_64-w64-mingw32-clang-3.2-release-win64_rubenvb.7z pointed to by the latter page, but had problems with the libstdc++-6.dll crashing. I have tried using some of the other files that might be more appropriate for a 32 bit install, but I have yet to find the magic combination that does not crash the same dll. I have searched for other dlls of the same name, and there are none on this system other than the one in the bin directory. Could someone suggest a working combination of clang/gcc for this processor/OS combination? Charles -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Some DLL-related issues remain
On 7/7/2013 1:43 PM, Charles Programmr wrote: I have tried following the setup according to Emscripten Tutorial (https://github.com/kripken/emscripten/wiki/Tutorial) and the page it refers to Using Emscripten on Windows (https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows). I initially tried using the files x86_64-w64-mingw32-gcc-4.6.3-2-release-win64_rubenvb.7z x86_64-w64-mingw32-clang-3.2-release-win64_rubenvb.7z pointed to by the latter page, but had problems with the libstdc++-6.dll crashing. Hmm. LLVM used to offer MinGW clang binaries... but it seems that is no longer the case. You can perhaps try my (fully static) current toolchain binaries[0]. If they fail, I may be incline to look into it... - Derek [0] http://chromashift.org/builds/i686-w64-mingw32-4.8.1.tar.xz http://chromashift.org/builds/x86_64-w64-mingw32-4.8.1.tar.xz They need to be extract using MSYS tar, or symlinks wont be properly handled. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Some DLL-related issues remain
Thanks for the reply, Derek, After downloading these, I'm not seeing clang in these builds, or is there something I'm perceptually missing? Am I supposed to dl source code from somewhere for clang? Forgive me, I'm just getting started with the whole llvm thing after having read about Emscripten and asm.js. When you say LLVM used to offer MinGW clang binaries, where was the source of those files? Charles Hernandez On Sun, Jul 7, 2013 at 3:08 PM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 7/7/2013 1:43 PM, Charles Programmr wrote: I have tried following the setup according to Emscripten Tutorial ( https://github.com/kripken/emscripten/wiki/Tutorial) and the page it refers to Using Emscripten on Windows ( https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows). I initially tried using the files x86_64-w64-mingw32-gcc-4.6.3-2-release-win64_rubenvb.7z x86_64-w64-mingw32-clang-3.2-release-win64_rubenvb.7z pointed to by the latter page, but had problems with the libstdc++-6.dll crashing. Hmm. LLVM used to offer MinGW clang binaries... but it seems that is no longer the case. You can perhaps try my (fully static) current toolchain binaries[0]. If they fail, I may be incline to look into it... - Derek [0] http://chromashift.org/builds/i686-w64-mingw32-4.8.1.tar.xz http://chromashift.org/builds/x86_64-w64-mingw32-4.8.1.tar.xz They need to be extract using MSYS tar, or symlinks wont be properly handled. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
