[Mingw-w64-public] There is no mingw-w64 (GCC) 4.8 Linux x86_64 binary
Dear maintainers, I want to use mingw-w64 (GCC) 4.8 on Ubuntu 12.04/13.10 64-bit. But the version we can install on Ubuntu 12.04/13.10 is mingw-w64 (GCC) 4.6.3. And I also cannot find mingw-w64 (GCC) 4.8 Linux x86_64 binary at official website. (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/ ). I can only find mingw-w64 (GCC) 4.7 and 4.9 Linux x86_64 version. Could you help to publish a mingw-w64 (GCC) 4.8 Linux x86_64 binary on the official website? I also tried to build from the source mingw-w64-v2.0.7 by the following steps. #1 ./configure -host=x86_64-w64-mingw32 #2. make I encountered compiling errors as below when compiling tool chain is mingw-w64 (GCC) 4.6: intrincs/bittestci.c:13:15: error: conflicting types for 'InterlockedBitTestAndComplement' /usr/lib/gcc/x86_64-w64-mingw32/4.6/../../../../x86_64-w64-mingw32/include/intrin.h:1042:5: note: previous declaration of 'InterlockedBitTestAndComplement' was here make[3]: *** [intrincs/lib32_libmingwex_a-bittestci.o] Error 1 make[3]: Leaving directory `/home/android/source-code/dliu32x/mingw-w64-v2.0.7/mingw-w64-crt' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/android/source-code/dliu32x/mingw-w64-v2.0.7/mingw-w64-crt' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/android/source-code/dliu32x/mingw-w64-v2.0.7' make: *** [all] Error 2 Then I changed the compiling tool chain to a local mingw-w64 (GCC) 4.9 20131228 (experimental). It threw below errors: In file included from /home/android/source-code/mingw-w64/x86_64-w64-mingw32/include/intrin.h:41:0, from intrincs/writecr0.c:7: /home/android/source-code/mingw-w64/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:1309:1: note: previous definition of '__writecr0' was here __build_writecr(__writecr0, unsigned __LONG32, 0) ^ make[3]: *** [intrincs/lib32_libmingwex_a-writecr0.o] Error 1 make[3]: Leaving directory `/home/android/source-code/dliu32x/mingw-w64-v2.0.7/mingw-w64-crt' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/android/source-code/dliu32x/mingw-w64-v2.0.7/mingw-w64-crt' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/android/source-code/dliu32x/mingw-w64-v2.0.7' make: *** [all] Error 2 Do you have any idea about these compiling errors ? And if I did something wrong, please tell me. And I look forward to see that mingw-w64 (GCC) 4.8 Linux x86_64 binary can be downloaded at the official website. If anyone has a personal build of mingw-w64 (GCC) 4.8 Linux x86_64 binary, welcome to contact with me. Thanks. Best regards, Dongxing Liu -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler
but I thought that it was said here that the win32 version does not work with sjlj in a stable way - yet? From: Kai Tietz ktiet...@googlemail.com To: mingw-w64-public@lists.sourceforge.net mingw-w64-public@lists.sourceforge.net Sent: Thursday, February 20, 2014 1:14 AM Subject: Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler 2014-02-20 1:16 GMT+01:00 Ciro Cornejo ciro.corn...@wdc.com: Seriously? !!! Come on guys, this makes the compiler unusable. What? ...but as long as you're making a toy compiler, would you consider making one that does not support pthreads and so avoids this problem? Why we should make a compiler which doesn't support pthreads? pthreads is a user-library and it is up to you to use it or not. Thanks. Hi! Sorry for the interruption, but you may want to take at least a few seconds to look into some recent license changes for the software you're about to install. What license-changes? Yes, winpthread uses a more liberal license for developers as other win32 based pthread libraries do. So yes, it is a BSD license, and therefore you might need to mention that you are using is it. This is just fair. Parts of the winpthreads library will be compiled into every binary file (EXE That isn't true. First this applies only to gcc-version built with posix-threading model. For it, either it is linked in as shared library, or if you request it as static library. If you don't want to rely on posix-threading-model, then simply don't use it and choose a toolchain buiild with win32-threading mode (by the way the default configuration). I would advice you to look in more detail to license issues. MS compiler has them, and gcc mingw(-w64) do so too. You will be wondering what other licenses you are using for just building a simple hello-world-application with mingw(-w64). For getting an idea you might to take a look to the COPYING.MinGW-w64-runtime license. You seem to mix here the term free software with free for nothing software, and copy other people's work without acknowledge it. or DLL) you create. It's a necessary evil that is currently required in order to provide support for threads and concurrency in programs compiled by GCC. The license for winpthreads requires you to reproduce its text in every copy or substantial portion of the winpthreads library that you distribute. This means that even if you just want to distribute a single small executable, created with TDM-GCC (or any winpthreads-based GCC release), you must include a copy of that license. INAL, but in general you might be right. If you want to be fair, you should need to mention other derived work you are using in your application too. We see this pretty liberal, nevertheless people like you are showing to us that we might should reconsider about that. Check the license out in the file COPYING.winpthreads.txt, which will be Where you see COPYING.winpthreads.txt file? It isn't part of winpthread. We have there a file named COPYING. I assume you are referring to that. Regards, Kai -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler
On Thu, Mar 20, 2014 at 8:33 AM, Jim Michaels jmich...@yahoo.com wrote: but I thought that it was said here that the win32 version does not work with sjlj in a stable way - yet? You've resurrected a month old thread with an email that is 100% non-sequitur. At no point in this this thread has anyone mentioned sjlj. Also, you are talking about some object or product without any indication of what it is, nor who it was here who said that about it. Would it be possible for you to connect the dots please? From: Kai Tietz ktiet...@googlemail.com To: mingw-w64-public@lists.sourceforge.net mingw-w64-public@lists.sourceforge.net Sent: Thursday, February 20, 2014 1:14 AM Subject: Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler 2014-02-20 1:16 GMT+01:00 Ciro Cornejo ciro.corn...@wdc.com: Seriously? !!! Come on guys, this makes the compiler unusable. What? ...but as long as you're making a toy compiler, would you consider making one that does not support pthreads and so avoids this problem? Why we should make a compiler which doesn't support pthreads? pthreads is a user-library and it is up to you to use it or not. Thanks. Hi! Sorry for the interruption, but you may want to take at least a few seconds to look into some recent license changes for the software you're about to install. What license-changes? Yes, winpthread uses a more liberal license for developers as other win32 based pthread libraries do. So yes, it is a BSD license, and therefore you might need to mention that you are using is it. This is just fair. Parts of the winpthreads library will be compiled into every binary file (EXE That isn't true. First this applies only to gcc-version built with posix-threading model. For it, either it is linked in as shared library, or if you request it as static library. If you don't want to rely on posix-threading-model, then simply don't use it and choose a toolchain buiild with win32-threading mode (by the way the default configuration). I would advice you to look in more detail to license issues. MS compiler has them, and gcc mingw(-w64) do so too. You will be wondering what other licenses you are using for just building a simple hello-world-application with mingw(-w64). For getting an idea you might to take a look to the COPYING.MinGW-w64-runtime license. You seem to mix here the term free software with free for nothing software, and copy other people's work without acknowledge it. or DLL) you create. It's a necessary evil that is currently required in order to provide support for threads and concurrency in programs compiled by GCC. The license for winpthreads requires you to reproduce its text in every copy or substantial portion of the winpthreads library that you distribute. This means that even if you just want to distribute a single small executable, created with TDM-GCC (or any winpthreads-based GCC release), you must include a copy of that license. INAL, but in general you might be right. If you want to be fair, you should need to mention other derived work you are using in your application too. We see this pretty liberal, nevertheless people like you are showing to us that we might should reconsider about that. Check the license out in the file COPYING.winpthreads.txt, which will be Where you see COPYING.winpthreads.txt file? It isn't part of winpthread. We have there a file named COPYING. I assume you are referring to that. Regards, Kai -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
[Mingw-w64-public] -shared vs. -mdll
Hi list, with mingw-w64, I'm used to build DLLs with gcc linker option -mdll. I am currently playing with CMake as I consider to leave manually maintained Makefiles behind me. It seems CMake prefers -shared over -mdll. I cannot find any docs how the two options differ. So, which one is the right one for normal DLL? Should I convince CMake that -mdll is better? And one bonus question (a bit off-topic for this list): If I should to convince it, do you know how? When I tried to use set(CMAKE_SHARED_LINKER_FLAGS -mwindows -mdll) then I've got an error: gcc.exe: error: shared and mdll are not compatible I also tried cmake -LAH to see where -shared comes from but it does not uncover that. Thanks for any info or pointers, Martin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] -shared vs. -mdll
http://comments.gmane.org/gmane.comp.gnu.mingw.user/9155 On Thu, Mar 20, 2014 at 10:08 PM, Martin Mitáš m...@morous.org wrote: Hi list, with mingw-w64, I'm used to build DLLs with gcc linker option -mdll. I am currently playing with CMake as I consider to leave manually maintained Makefiles behind me. It seems CMake prefers -shared over -mdll. I cannot find any docs how the two options differ. So, which one is the right one for normal DLL? Should I convince CMake that -mdll is better? And one bonus question (a bit off-topic for this list): If I should to convince it, do you know how? When I tried to use set(CMAKE_SHARED_LINKER_FLAGS -mwindows -mdll) then I've got an error: gcc.exe: error: shared and mdll are not compatible I also tried cmake -LAH to see where -shared comes from but it does not uncover that. Thanks for any info or pointers, Martin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
