Re: [Mingw-w64-public] What is the default download on sourceforge?
On Tue, Feb 25, 2014, Baruch Burstein wrote: Hi all, On the Sourceforge page for mingw64 ( http://sourceforge.net/projects/mingw-w64/) the is a download button. On Sourceforge, this default download is usually reserved for the most common download, the file(/archive) that most people looking to use this software are going to want. For mingw64 I would expect it to be the x86-x86 compiler suite. Instead, it is a 7 MB file (named mingw-w64-v3.1.0.tar.bz2). When I opened it I couldn't even figure out what it is. Why/when/who would need this file? What is it? And why is it the default download? This is the sources of mingw-w64 itself. A toolchain is binaries made from other projects too (GCC + binutils + mingw-w64). -- Adrien Nader -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] What is the default download on sourceforge?
On Tue, Feb 25, 2014, Adrien Nader wrote: On Tue, Feb 25, 2014, Baruch Burstein wrote: Hi all, On the Sourceforge page for mingw64 ( http://sourceforge.net/projects/mingw-w64/) the is a download button. On Sourceforge, this default download is usually reserved for the most common download, the file(/archive) that most people looking to use this software are going to want. For mingw64 I would expect it to be the x86-x86 compiler suite. Instead, it is a 7 MB file (named mingw-w64-v3.1.0.tar.bz2). When I opened it I couldn't even figure out what it is. Why/when/who would need this file? What is it? And why is it the default download? This is the sources of mingw-w64 itself. A toolchain is binaries made from other projects too (GCC + binutils + mingw-w64). Also, I'd say the usual and expected entrypoint would be the _website_ download page, not the SF one. -- Adrien Nader -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Building a library for use under Visual Studio 2008
Hello, I use MingGW64 for my development work on Windows 7 64 bit. Essentially, I build libraries via ar rvs libfoo.a *.o files and test the libraries by linking to a test harness that has main(). I use -std=c++0x and -static-libgcc -static-libstdc++ flags. Can my lib*.a files be used by others who work inside Visual Studio 2008 (which does not support the latest C++ standard library)? I can make sure that the header files needed by others do not use the newer C++ features. If my lib*.a files cannot be used in a Visual Studio 2008 project, what would I need to do to build a library that can be used by others who work inside Visual Studio 2008? While I am familiar with generating and using lib*.a files, I have no clue about dll files. Thanks, --Suresh -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h
Hi,
On Wed, Feb 19, 2014, Jacek Caban wrote:
Hi Adrien,
On 02/17/14 21:18, Adrien Nader wrote:
On Wed, Feb 12, 2014, Kai Tietz wrote:
2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com:
On 02/12/14 08:57, Adrien Nader wrote:
Hi,
I recently stumbled on an issue where dvec.h gets included from intrin.h
and triggers around 140 different not declared in this scope errors.
Basically, there is an #include dvec.h (which is a C++-only header)
near the top of intrin.h and the function declarations for non-SSE2
bulds come later on (I guess that if SSE2 is used, the compiler already
has declarations for them?). Since dvec.h uses functions which are
declared later on, compilation errors out.
Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be
included from intrin.h. I've tried remove them and my build issues went
away.
Should that change be commited? Should it also be backported to the
stable branch?
IMO we should remove them in trunk, but not stable branch (at least not
without a delay). We won't know if we're breaking real world code until
we do that.
Jacek
For trunk this change seems to be right. For branches I agree to
Jacek that we shouldn't do the change.
Kai
Back from my short vacations, patch would be:
diff --git a/trunk/mingw-w64-headers/crt/intrin.h
b/trunk/mingw-w64-headers/crt/intrin.h
index 6287610..2348e09 100644
--- a/trunk/mingw-w64-headers/crt/intrin.h
+++ b/trunk/mingw-w64-headers/crt/intrin.h
@@ -147,11 +147,6 @@ extern C {
}
#endif
-#if defined(__cplusplus)
-#include dvec.h
-#include fvec.h
-#include ivec.h
-#endif
#endif
#define __MACHINEX64 __MACHINE
I have no idea what the commit message would be however. :P
Also, I agree that this should only go to trunk, not stable branches
since it changes behaviour. It is however something I will integrate in
win-builds.org.
Thanks for the patch. I believe we may consider it as approved. Do you
need me to commit the patch?
Sorry for the delay, I've commited this as rev 6501 intrinsics: don't
include {d,f,i}vec.h from inside intrin.h..
--
Adrien Nader
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Which MinGW-w64 build to use under Windows for libusb
On Tue, Feb 18, 2014 at 9:08 AM, Xiaofan Chen xiaof...@gmail.com wrote: Ref: http://marc.info/?l=libusb-develm=139259972118999w=2 I'd like to seek the advice from MinGW-w64 project on which compiler to use to build libusb binary (now that libusb and libusbx project are merged, we will refer to them as libusb). My understanding is that libusb is a C only project so that the exception handling does not matter, right? I am not so sure if the threading model affects libusb or not. libusb Windows backend uses Windows native threading. Will a posix MinGW-w64 GCC creates problem for libusb Windows binary built with the posix MinGW-w64 GCC? Pete's concern: http://marc.info/?l=libusb-develm=139260143019289w=2 libusb Windows backend thread codes https://github.com/libusb/libusb/blob/master/libusb/os/threads_windows.c Just want to check if anyone has any suggestions here. Thanks. If there is no answer, we will probably choose to use win32 threading model to build the official binary. -- Xiaofan -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Which MinGW-w64 build to use under Windows for libusb
If you are not sure I'd suggest you use win32. http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo http://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32 It is always wiser to make good use of what the operating system has provided than to settle for an apple of Sodom - here, POSIX. If being potable is not the primary objective then POSIX is meaningless. -- Best regards, lh_mouse 2014-02-26 - 发件人：Xiaofan Chen xiaof...@gmail.com 发送日期：2014-02-26 14:54 收件人：mingw64 抄送： 主题：Re: [Mingw-w64-public] Which MinGW-w64 build to use under Windows for libusb On Tue, Feb 18, 2014 at 9:08 AM, Xiaofan Chen xiaof...@gmail.com wrote: Ref: http://marc.info/?l=libusb-develm=139259972118999w=2 I'd like to seek the advice from MinGW-w64 project on which compiler to use to build libusb binary (now that libusb and libusbx project are merged, we will refer to them as libusb). My understanding is that libusb is a C only project so that the exception handling does not matter, right? I am not so sure if the threading model affects libusb or not. libusb Windows backend uses Windows native threading. Will a posix MinGW-w64 GCC creates problem for libusb Windows binary built with the posix MinGW-w64 GCC? Pete's concern: http://marc.info/?l=libusb-develm=139260143019289w=2 libusb Windows backend thread codes https://github.com/libusb/libusb/blob/master/libusb/os/threads_windows.c Just want to check if anyone has any suggestions here. Thanks. If there is no answer, we will probably choose to use win32 threading model to build the official binary. -- Xiaofan -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] What is the default download on sourceforge?
Hi, On Tue, Feb 25, 2014, Baruch Burstein wrote: Hi all, On the Sourceforge page for mingw64 ( http://sourceforge.net/projects/mingw-w64/) the is a download button. On Sourceforge, this default download is usually reserved for the most common download, the file(/archive) that most people looking to use this software are going to want. For mingw64 I would expect it to be the x86-x86 compiler suite. Instead, it is a 7 MB file (named mingw-w64-v3.1.0.tar.bz2). When I opened it I couldn't even figure out what it is. Why/when/who would need this file? What is it? And why is it the default download? I hadn't understood why you were going to the sourceforge download page rather than the one on the website. I learnt from a new user on IRC on yesterday that the big download button on the website was still pointing to the sourceforge page and I've changed it. Of course, this is only a link change; it doesn't change anything in the organization but the hope is that the website's download page will be simpler for new users (although there is still work to do on it). -- Adrien Nader -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Which MinGW-w64 build to use under Windows for libusb
On Wed, Feb 26, 2014 at 3:06 PM, Adrien Nader adr...@notk.org wrote: Hi, On Wed, Feb 26, 2014, Xiaofan Chen wrote: On Tue, Feb 18, 2014 at 9:08 AM, Xiaofan Chen xiaof...@gmail.com wrote: Ref: http://marc.info/?l=libusb-develm=139259972118999w=2 I'd like to seek the advice from MinGW-w64 project on which compiler to use to build libusb binary (now that libusb and libusbx project are merged, we will refer to them as libusb). My understanding is that libusb is a C only project so that the exception handling does not matter, right? I am not so sure if the threading model affects libusb or not. libusb Windows backend uses Windows native threading. Will a posix MinGW-w64 GCC creates problem for libusb Windows binary built with the posix MinGW-w64 GCC? Pete's concern: http://marc.info/?l=libusb-develm=139260143019289w=2 libusb Windows backend thread codes https://github.com/libusb/libusb/blob/master/libusb/os/threads_windows.c Just want to check if anyone has any suggestions here. Thanks. If there is no answer, we will probably choose to use win32 threading model to build the official binary. Exception handling indeed only matters for C++. Good. libusb is C only. As for threading model, it matters for C but only for C11. I don't think libusb is C11 nor does use threading. As such you shouldn't have any issue with that. In other words, you can take a toolchain with any feature set and it should work. libusb does use threading, at least for hotplug which is not integrated into Windows backend yet but it will be quite soon. Ref code for hotplug code under Linux, Mac OS X and Windows (to be integrated) https://github.com/libusb/libusb/blob/master/libusb/os/linux_udev.c https://github.com/libusb/libusb/blob/master/libusb/os/darwin_usb.c https://github.com/manuelnaranjo/libusbx/blob/windows-hotplug-2/libusb/os/windows_usb.c That said, I wonder if using binaries built with a toolchain not using the posix threading model are incompatible with toolchains which use it. That is the worry. We actually tried to made the dll produce by different toolchain compatible (MSVC 32/64bit, MinGW.org 32bit only and MinGW-w64 32bit/64bit). Btw, about: threading. Will a posix MinGW-w64 GCC creates POSIX threading model doesn't mean the GCC is POSIX; it is only the API used by GCC which is POSIX-style and implemented through a fully native Windows library. I'll see how I can improve the wording on the download page. Thanks. -- Xiaofan -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Which MinGW-w64 build to use under Windows for libusb
On Wed, Feb 26, 2014, lh_mouse wrote: If you are not sure I'd suggest you use win32. http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo http://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32 It is always wiser to make good use of what the operating system has provided than to settle for an apple of Sodom - here, POSIX. If being potable is not the primary objective then POSIX is meaningless. I beg to disagree. In particular, everything in winpthreads comes from Windows; it is a library like any other and is built on Windows APIs. POSIX in the name is because the API follows pthreads', i.e. POSIX threads. It is _only_ a matter of exposed API. The whole idea behind pthreads-win32/winpthreads is to simplify source code compatibility between platforms. I think that ironically, it also helps quite a lot for compatibility with pre-vista versions. So what does GCC use this POSIX threading model for? Well, its internals simply don't know how the Windows threading APIs and it goes through that compatibility layer that is winpthreads. That's it. -- Adrien Nader -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
