search

mrosenbladt / yaml-cpp

Automatically exported from code.google.com/p/yaml-cpp
MIT License
0 stars 0 forks source link

Build with clang++ in c++11 mode #211

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
With clang++ 4.0 (Apple, based on 3.1) in c++11 mode, the compiler refuses to 
use the implicit copy constructor of iterator_value. It alternatively says that 
it is implictly deleted, or that there is an ambiguity with the 
iterator_value(const Node&) constructor (Node being a superclass of 
iterator_value). This change resolves the ambiguity in favor of calling the 
formerly-implicit copy constructor by making it explicit.

I'm not sure if the right thing to do is instead to call the const Node& 
constructor. The behaviors are different.

What steps will reproduce the problem?
1. Build yaml-cpp 0.5.1 with clang++ in c++11 mode (-std=c++11 -stdlib=libc++).

Original issue reported on code.google.com by antonbac...@yahoo.com on 28 Jun 2013 at 4:18

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by jbe...@gmail.com on 22 Jul 2013 at 1:16

GoogleCodeExporter commented 9 years ago 
I had a somewhat related issue that I solved. I thought putting my findings 
here might be useful if anyone else encounters the same problems.

I built yaml-cpp as instructed using cmake and make. Everything was happy until 
I tried to link to it in an Xcode project. I turns out the defaults (currently) 
are to use c++11 variants and to link against libc++ (NOT libstdc++). The link 
step failed in the Xcode project, but I could get everything to work using g++ 
from the commandline.

I didn't realize it at first, but I was running into libc++ and libstdc++ 
incompatibility (see 
http://stackoverflow.com/questions/12542971/using-libstdc-compiled-libraries-wit
h-clang-stdlib-libc for more info). The fix was to make sure that yaml-cpp was 
also compiled with libc++ instead of libstdc++ (there were reasons we needed to 
stick with those for the main project).

Hope this helps someone eventually :)

Original comment by Barrett....@gmail.com on 28 Jan 2014 at 5:43

GoogleCodeExporter commented 9 years ago 
I'm not sure if this is valid any more (sorry it took me so long to get to). I 
just tested with:

$ clang --version
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

by running

$ mkdir build
$ cd build
$ cmake -DCMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++" ..
$ make

and it builds successfully.

I tried this both at HEAD and at 0.5.1.

Can you reproduce this any more?

Original comment by jbe...@gmail.com on 23 Mar 2014 at 4:44

GoogleCodeExporter commented 9 years ago 
I can't reproduce this with my current version of clang with either HEAD or 
0.5.1, so it's probably not valid. I scanned the clang changelogs and mailing 
lists for information on whether they fixed a bug, but didn't find anything.

$ clang --version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

Original comment by antonbac...@yahoo.com on 23 Mar 2014 at 5:04

GoogleCodeExporter commented 9 years ago 
Thanks for taking a look!

Original comment by jbe...@gmail.com on 23 Mar 2014 at 8:03