views:

251

answers:

1

Browsing through a Currency in C++0x book and thought I would give the sample code a run. It is as basic as it gets.

#include <iostream>
#include <thread>

void hello()
{
    std::cout<<"Hello Concurrent World\n";
}


int main(int argc, char *argv[])
{
    std::thread t(hello);

    t.join();
}

Compiled with:

g++ -std=c++0x -g -o pgm pgm.cpp

Goes boom with:

Program received signal SIGSEGV, Segmentation fault.
_dl_fixup (l=0x7ffff7b0992c, reloc_arg=<value optimized out>) at ../elf/dl-runtime.c:147
147     ../elf/dl-runtime.c: No such file or directory.
        in ../elf/dl-runtime.c

Appears to be a setup/library issue of some kind. Anyone familiar with this?

+18  A: 

You need to compile/link using the -pthread flag.

nos
Head slap! That's it.
unknown google user
Shouldn't the C++ implementation take care of this detail? Otherwise, what use is there in having std::thread?
anon
I don't understand why it doesn't give linker errors.
Joey Adams
@Neil Butterworth: The point in having `std::thread` is a platform-independent, standard threading API. Compiler flags are a different thing.
lunaryorn
@lunaryorn The point is, I can use std::ostream without any linker switches. If I can't do the same with std::thread then it is not portable, and I won't use it.
anon
@Neil: of late you've been getting very grumpy: "I don't like boost, the new standard is crap etc," I don't know if its because of old age or something, but you should either get a life or retire.
dman
@dman - Perceived misanthropic tendencies aside, I think Neil is right about this one. It is one thing to have pthreads separate when the language claims to "know nothing about" threads. When threads are part of the core language...not so much. Of course, this raises the issue of what to do with the half of the pthreads functions - and their counterparts on other platforms - that you can only get at with the C++0x via native_handle() functions.
Duck
@Duck: The problem is the compiler. I use stdio and stdlib, the compiler is smart enough to provide the necessary code to either statically link them in or dyn-link them at runtime, without me having to explicitly link or load them. Once gcc get their act together it will be the same also, so the short of it is that its not c++0x's fault but rather the compiler implementation, and old grumpy folk shouldn't balk at progress.
dman
@Neil Butterworth: The C++0x is still an experimental extension to g++ I am betting that when g++ officially supports the new standard then they will have all the bugs fixed but for now I think it may be worth filling a bug report with the gcc team.
Martin York
@dman - I guess we agree then. I was actually thinking in terms of gcc but to be honest I don't know if there is anything in the standard that compels those smarts.
Duck
@Neil Butterworth: Don't make a drama of a single compiler flag. Of course, a standard library shouldn't require additional flags, but `std::thread` isn't standard (not yet). Once C++0x and its implementations are final, things may and most likely will change. For now, you may not use `std::thread`, but then you just need other flags to enable alternatives like TBB or OpenMP. Compiler and linker flags are a necessary evil, so try to get along with it ...
lunaryorn
@dman I use boost in several of my own projects, which I wouldn't do if I didn't like it. My main problem with it is the fanboy tendency here who see it s the only answer to every problem. I have certainly never, ever said the new standard is crap.
anon