I've been trying multithreaded C++. I installed the new Dev C++ 5.4.1 and added -std=c++11 to the compiler options. Then I added #include <thread> somewhere in my source code, and std::thread mythread (some_func).
When I compile the source file, I get a compiler error "thread defined in this scope".
What do I have to do to have it working?
You have to get the correct package of Mingw like sad here:
http://gameprog.it/articles/90/c-11-getting-started-on-windows
the package is found at:
http://sourceforge.net/projects/mingwbuilds/
The article is about code::blocks, but you can easily setup DevC++ too. Just pay a bit care about file names.
There's no longer need for boost threads at all. (Boost still remain a very good library and I encourage you to take a deeper look, but that is out of topic)
Official build of MinGW (that compiler Dev-C++ uses) has no support for standard library threads now.
You can use boost::thread as a drop in replacement (API is similiar enough) or use Microsoft Visual C++, or try programming with g++ on Linux (this is what I have done recently, using a virtual machine).
Related
I've come across an issue whilst trying to compile the latest branch of grpc under MSYS2, using mingw64 as suggested by the official installation guide.
The latest gcc for msys2 is 5.2.0, which isn't exactly on good terms with grpc. Still, downgrading to 4.9.1 helped a bit. Through a lot of manual editing of the makefile and a couple C headers, I was finally able to compile all the dependencies. As far as I can tell, most objects had successfully compiled. However, make keeps failing with the error "no target to make libgrp.dll, required by shared_c"(might not be perfect wording). I end up with botched static libs that are recognized by Qt as lacking symbols.
I would greatly appreciate a reliable compilation guide for grpc, and/or precompiled binaries fit for Qt 5.5 32-bit. I know the project is not too mature just yet, but it looks very promising and I can't wait to work with it!
Many thanks!
You're right that mingw isn't quite a first class citizen for grpc, but it's something we're looking to work on soon. Please file bugs at http://github.com/grpc/grpc/issues for anything you find!
That said, we do test the C codebase against Visual Studio 2013 regularly. I expect C++ to be tested regularly soon, along with VS2015. Could VS2015 be the solution to your problems, given it's now a free download?
So I spent all day trying to get c++ threads to work with eclipse Kepler and mingw. I have tried adding the -std=c++11 flag, -lpthread flag, another flag and even added a symbol to the table GXX_EXPERIMENTAL_CXX0X. My latest attempt at getting threads to work is to follow this advice
std::thread is not a member of namespace std using Eclipse Kepler MinGW
which says:
Plain MinGW cannot support std::thread. You will need to use a
MinGW-w64 toolchain (such as those shipped with Qt 5) that has "posix"
threading enabled, so that libstdc++ exposes the thread, mutex and
future functionality. You can find an installer here.
Now I have a folder called:
C:\Program Files\mingw-builds\x64-4.8.1-posix-seh-rev5
How do I get this to work with eclipse so I can use threading? Do I have to replace something in my mingw file or somehow link this to eclipse? I have no clue where to even begin.LET ALONE if this is recommended.
Take a look at this FAQ
I think it is along the lines of what you want to do because basically you need to show eclipse a different version of MinGW. It looks like you'll need to set the PATH variable correctly so eclipse can find the new version.
I was trying to use the boost library first time. Using as an environment Eclipse 4.3 with CDT and as compiler gcc 3.4 and boost 1.53.
I was browsing various sites to find info on how to setup boost, but it doesn't seem to work. When I compile trying to include boost/asio.hpp I get the error:
You must add -D__USE_W32_SOCKETS to your compiler options
However, I don't want to use windows sockets, I want to use posix, so I don't really know what is wrong. As I need the project to run on HP-UX later, I dont want to get to Windows specific. If I use now windows sockets will the program later be easily portable to Unix, or are all the details encapsulated in boost, and I don't have to care anyway?
I tested a simple testprogram using FOREACH loop to confirm that boost itself works, and this is the case.
I also found this: https://svn.boost.org/trac/boost/ticket/7881 so does it mean that this problem is currently currently not supported, or am I doing something wrong?
It seems what you're trying to do is not supported by the library, the documentation states the following under supported platforms
The following platforms and compilers have been tested:
Win32 and Win64 using Visual C++ 7.1 and Visual C++ 8.0.
Win32 using MinGW.
Win32 using Cygwin. (__USE_W32_SOCKETS must be defined.)
Linux (2.4 or 2.6 kernels) using g++ 3.3 or later.
Solaris using g++ 3.3 or later.
Mac OS X 10.4 using g++ 3.3 or later.
added emphasis is mine. If that's not possible, you might try the patch suggested in the linked ticket. However, grepping through the source code I see several occurrences of #if !defined(BOOST_WINDOWS) && !defined(__CYGWIN__) so it's not obvious that simply patching io_service.hpp will resolve anything. You might try adding -U__CYGWIN__ to your CXXFLAGS, though the cygwin toolchain may not like that.
Full disclosure: I am not a Windows guy so hopefully someone else will chime in.
The libboost-devel package in the Cygwin distribution includes patches to not use Winsock on Cygwin in Boost.Asio. I suggest trying that in conjunction with the gcc4 packages, which provide more recent versions of GCC.
Trying to compile a C++ kernel project with MinGW & NASM (formerly DJGPP & NASM). Have actually tried Cygwin too, with the exact same results below:
First, just swapped out \DJGPP\bin for \MinGW\bin. Got the following link error: target coff-go32 not found.
Swapped target to elf32-i386, and got cannot perform PE operations on non PE output file 'build/kernel.elf' This was a bit of a weird error, since to my knowledge I'm not doing any 'PE operations'.
Changed target again, to pe-i386, got a new error build/Common.o:Common.cc:(.text+0x2a): undefined reference to 'atexit'
It seems MinGW is generating atexit calls for static classes. DJGPP did not. The kernel does it's own DTOR handling during shutdown. I am aware that defining atexit would 'solve' this, but that would be more of a hack at this point, and not a longterm solution. I want rather to get MinGW compiling the existing code without any (or minimal) modifications.
Frankly, I'm not that familiar with the Windows build environment and could use any tips on what to do. The project (minus the changes listed above) compiles and boots fine under DJGPP. The difference seems to be in the way DJGGP and MinGW handle compile-time class declarations?
EDIT: Finally broke down and built a cross-compiler on Cygwin. All working now.
You need to build a free-standing cross compiler. This problem has been referenced many times at the OSDev Wiki to the point that most people recommend you begin writing a kernel by first creating a cross compiler.
This article will provide a step-by-step reference to building your own cross compiler. Note, in Windows, you may have to build the cross compiler using MingW or Cygwin
I want to build cross-platform statically linked library in C++.
How am I supposed to do this(I am a complete NOOB, never been using g++,gcc,mingw etc I looked on the internet for a solution to my problem, but didn't find anything. Except that mingw is a Minimalist GNU for Windows...)? I've been always using Visual c++ on windows, but now I have to build lib which will be attached to Qt projects for: windows,mac,linux.
If anyone know a good tutorial, on using compilers, and how to build libraries, I'll appreciate sharing them here :)
Thanks, may the force be with you.
MinGW is a very good compiler! I use it all the time. Even though MinGW stands for Minimalist GNU for Windows, MinGW has everything you need to program in either C++ or C. If you are creating a QT Application, I recommend using QT Creator (just google it). I haven't used it lately, but I think it supports Cross-Platform compiling (as does MinGW, with some command-line commands...).
The best way to cross-compile though, is but getting a copy of each OS that you are going to compile for. So if you are doing Windows, Mac, and Linux, I recommend getting one of each (Mac OS X is around $25 and Linux is free). Then just use the included compilers (XCode on Mac; GCC on Linux) to compile. Unfortunately when you are performing cross compiling, you need to support each OS individually (some parts can shared between OSes).
Since you will be using a toolkit (QT), you probably don't have to worry much about platform specific calls or anything. Just make sure you use the QT typedefs and structs and not the Microsoft Windows ones...