Clang C++11 having a rough time

[Levi Schuck]

So, in my failed attempt to modify v8's GYP project files to put in extra cflags being -std=c++11 -stdlib=libc++,

I converted v8 (at least the x64 portion) to cmake so I actually understood what was going on. 

After replicating the convoluted process, I finally got a libv8.dylib built. Note at this point, I wasn't throwing in the new std lib yet.

I've put my cmake-ified version here https://github.com/kloplop321/v8

I then took cvv8, adjusted the config.make to include the flags (I had to add a few because of clang's warning pragmatism)

-Wall -Werror -fPIC -Wno-vexing-parse -Wno-unused-functiony -Wno-unused-variable

Finally, I get the examples to compile and they seem to run correctly.

I then proceed to add in the -std=c++11 -stdlib=libc++ flags to my cmake version, and the config.make inside of cvv8.

It seems to go well until I hit where it tries to build the shell and demo and then it pukes out

 + clang++ -o demo -fPIC -stdlib=libc++ -std=c++11 -Wno-vexing-parse -g -O0 demo.o ConvertDemo.o -L/opt/local/lib -lpthread -L/Users/kloplop321/lib -lv8

Undefined symbols for architecture x86_64:

  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::c_str() const", referenced from:

      cvv8::InCaCatcher<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, char const* ()(), &(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::c_str() const), cvv8::FunctionToInCa<void ()(), &(throwStdString()), true>, false>::Call(v8::Arguments const&) in ConvertDemo.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

 

This made hardly any sense, as I threw in the old std lib, or the lack of one and it would complain about the typical stuff like ostream, but this one particular symbol it struggles with.

I believe this is a problem with libc++ from llvm, but I'm bringing it out as a notice..

The only way I got stuff to build was to comment out the infringing lines

("throwStdString",

                    InCaCatcher<std::string,

                        char const * (),

                        &std::string::c_str,

                        FunctionToInCa< void (), throwStdString >

                    >::Call)

inside of ConvertDemo.cpp

The reason why this seems to be happening, according to my educated guess, is that inside of the libc++ headers, that function is not only inlined, but also it later specifies that there's an extern template of the std::basic_string<char>.

The following code works fine anywhere in the same file..

void somefunction()
{
    std::string a = "blah";
    const char * b = a.c_str();
} 

Of course now I have to ignore unused variables or whatever, but it compiles.

 

What exactly are the ramifications for lacking this code in the example demo? 

Thanks, 

[Stephan Beal]

Hi, Levi!

My utmost apologies - i was offline from September until late December and completely missed this post. i _might_ have a suggestion about how to resolve this, but it's just a guess: adding -lstdc++ to the linker flags?

[Stephan Beal]

On Friday, November 9, 2012 5:09:22 AM UTC+1, Levi Schuck wrote: 

What exactly are the ramifications for lacking this code in the example demo? 

(And this time to answer the concrete question...)

The example of using std::string as an exception type was basically just to show that it "could" be done, not that it "should" be done. Removing that particular throw/catch example will not break anything (except maybe cause a test assertion which looks for it, but i don't recall if there is one). i wouldn't expect real code to use std::string in that way - i only used std::string there to avoid having to create a custom exception class to use as an example.

[levi....@gmail.com]

Hello Stephan,

I haven't done anything with v8 since I really wrote this, though I would like to at some point..

The problem with that is that linking in two standard libraries.. will cause problems because of symbol conflicts. 

--
You received this message because you are subscribed to a topic in the Google Groups "v8-juice-js-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-juice-js-dev/n97AdRKIgzc/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to v8-juice-js-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.