Strange behaviour with Gcc4.8 and C++11

[koala01]

Hello...

I just have compiled a personnal version of Gcc 4.8 with C++11 threads support.

When i compile a simple code like

Code Select Expand

#include <thread>
#include <iostream>

void doSomeWork( )
{
    std::cout << "hello from thread..." << std::endl;
    return;
}
int main( int argc, char *argv[] )
{
    std::thread t( doSomeWork );
    t.join();
    return 0;
}
directly from the windows command line with the correct options ( -static -std=c++11 <-m32>) , i have no problem : calling the executable just works fine.

If i compile the same code with the same options under C::B, execution fails on a std::system_error exception ("Enable multithreading to use std::thread : operation non permitted" )

has someone an idea on what' appens?

PS:

• 
  Gcc 4.8.0 (20130217)
  
• windows vista 64 bits
• svn "trunk" revision of mingw-w64
• svn "experimental" version of winpthread for thread support

[oBFusCATed]

Start from here: http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_a_compiler_problem.3F

[stahta01]

FYI:

After verifying the compiler command is exactly the same (including options are in the same order).

You will want to confirm the PATH being set to the same as CB does it is not the cause of the issue.

Tim S.

[koala01]

i have just understood where  is the probelm:

When compiling a c++ project, C::B calls g++ two time:
a first time to create the object file with command

Code Select Expand

g++ -std=c++11 -static -c main.cpp -o main.o(which is exactly the correct command we need)
and a second time to link the object file in an executable with the command

Code Select Expand

g++  -o programName.exe programName.exe
This is a normal behaviour since projects are, usually, composed by more than one single file

If Gcc has been build with (e g) --enable-shared, programs are by default linked with ... dll libraries version

As far as i know, it seems that there is a known problem when linking with shared libraries for stdc++ and winpthread.

But, as the problem can be resolved if linking is done with a command like

Code Select Expand

g++ -static -o programName.exe main.oit would (maybe) be interresting to ensure that -static option (if present) is correctly passed when using g++ for linking.

What do you thing about ?

[stahta01]

it would (maybe) be interresting to ensure that -static option (if present) is correctly passed when using g++ for linking.

What do you thing about ?

Yeah, it would be boring if we required people to put Linking Options in the place for Linker options.

Tim S.

PS: I prefer boring.