Ok that was an error on my end... So I finally managed to make it work! 

Glad to see that our recommendation worked for you :)

Now, a final question if you don't mind: do you plan to release a version which builds on libc++? That would be great! 

Well it is not actually needed, and here is why:

The actual symbols in the two STLs don't collide because the libc++ uses an inline namespace __1 in its symbols.  They are incompatible in all sorts of ways, but provided you don't try to pass an object that was allocated via one library into a function that was compiled against the other library, then it should be OK.  Since Vuforia does not expose any STL symbols in its API, this should never happen.

Hope this makes sense.

N

Ok that was an error on my end. We have a hierarchy of projects, with mutliple project settings that are set in multiple places and the project file I was editing had its settings overriden by another one.

So I finally managed to make it work! 

Now, a final question if you don't mind: do you plan to release a version which builds on libc++? That would be great! 

Yep, I put exactly the path you mentioned in the "Other Linker Flags" options under the "Linking" section.

Then, when I look at your linker output, why can I not find libstdc++.dylib in the linker command, as I can with the example below?

I set mine in XCode under Build Settings - see the attached picture.

N

Ld /Users/c_nalins/Library/Developer/Xcode/DerivedData/VuforiaSamples-gneaxxzmforykngqicxblgwhotch/Build/Products/Debug-iphoneos/Vuforia.app/Vuforia normal armv7s

    cd /Users/c_nalins/Documents/dev/vuforia-sdk-ios-3-1-2/samples/VuforiaSamples-3-1-2

    export IPHONEOS_DEPLOYMENT_TARGET=4.3

    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"

    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -L/Users/c_nalins/Library/Developer/Xcode/DerivedData/VuforiaSamples-gneaxxzmforykngqicxblgwhotch/Build/Products/Debug-iphoneos -L../../build/lib/arm -F/Users/c_nalins/Library/Developer/Xcode/DerivedData/VuforiaSamples-gneaxxzmforykngqicxblgwhotch/Build/Products/Debug-iphoneos -filelist /Users/c_nalins/Library/Developer/Xcode/DerivedData/VuforiaSamples-gneaxxzmforykngqicxblgwhotch/Build/Intermediates/VuforiaSamples.build/Debug-iphoneos/VuforiaSamples.build/Objects-normal/armv7s/Vuforia.LinkFileList -dead_strip /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib/libstdc++.dylib -fobjc-link-runtime -miphoneos-version-min=4.3 -framework CoreVideo -framework CoreMedia -framework AVFoundation -framework SystemConfiguration -framework OpenGLES -framework CoreMotion -framework Security -framework QuartzCore -framework UIKit -framework Foundation -framework CoreGraphics -lVuforia -Xlinker -dependency_info -Xlinker /Users/c_nalins/Library/Developer/Xcode/DerivedData/VuforiaSamples-gneaxxzmforykngqicxblgwhotch/Build/Intermediates/VuforiaSamples.build/Debug-iphoneos/VuforiaSamples.build/Objects-normal/armv7s/Vuforia_dependency_info.dat -o /Users/c_nalins/Library/Developer/Xcode/DerivedData/VuforiaSamples-gneaxxzmforykngqicxblgwhotch/Build/Products/Debug-iphoneos/Vuforia.app/Vuforia

Yep, I put exactly the path you mentioned in the "Other Linker Flags" options under the "Linking" section.

Mine is as follows:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib/libstdc++.dylib

(Note: I have "Xcode.app" under the Applications folder, not "Xcode_551.app", that's not an oversight).

EDIT: Are you by any chance planning on releasing a version that could build with libc++?

Hi

Just wondering why I cannot see the full path of libstdc++.dylib in the linker command?

/Applications/Xcode_511.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib/libstdc++.dylib

Did you specify the fully qualified pathname as per the orginal instruction?

cheers,

N

My linker command is as follows:

Ld /Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Products/Debug-iphoneos/Augment.app/Augment normal armv7
    cd /Users/jblort/git/appIos/AugmentApp
    export IPHONEOS_DEPLOYMENT_TARGET=6.0
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk -L/Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Products/Debug-iphoneos -L/Users/jblort/git/appIos/AugmentApp/../external_libraries/GoogleAnalytics/GoogleAnalyticsiOS_2.0beta4/Library -F/Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Products/Debug-iphoneos -filelist /Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Intermediates/Augment.build/Debug-iphoneos/Augment.build/Objects-normal/armv7/Augment.LinkFileList -dead_strip -ObjC -all_load -lstdc++ -fobjc-arc -fobjc-arc -fobjc-link-runtime -stdlib=libc++ -miphoneos-version-min=6.0 -framework UIKit -framework Accelerate -framework MediaPlayer -weak_framework Accounts -weak_framework Social /Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Products/Debug-iphoneos/libAugmentSdkIos.a -lsqlite3.0 -framework CoreMotion -framework MapKit -framework CoreLocation -framework MessageUI -framework ImageIO -lz.1.2.5 -framework AudioToolbox -framework MobileCoreServices -lxml2 -framework CFNetwork -weak_framework CoreTelephony -framework SystemConfiguration -framework Security -framework OpenGLES -liconv -framework QuartzCore -weak_framework CoreVideo -weak_framework CoreMedia -weak_framework AVFoundation -framework Foundation -framework CoreGraphics -framework CoreData -Xlinker -dependency_info -Xlinker /Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Intermediates/Augment.build/Debug-iphoneos/Augment.build/Objects-normal/armv7/Augment_dependency_info.dat -o /Users/jblort/Library/Developer/Xcode/DerivedData/Augment-gkyqzmfzrbggnzbalcteacfpxlyz/Build/Products/Debug-iphoneos/Augment.app/Augment

Though as already mentioned, it would be really better to be able to build using libc++ only. Indeed, there can be some nasty problem that could arise from the dual lib linking approach, as those two aren't ABI compatible, and this could result in tricky runtime bugs.

Thanks!

Hi

Could you please copy and paste from the build log the linker command showing all its parameters?

cheers

N

Hi! Thanks for your quick response.

Yes, I do know that Apple doesn't support beyond GCC 4.2 and that's precisely why we don't want to switch our whole project to libstdc++ and keep building with libc++.

Then, I have exactly the same linker errors as the OP, before _and_ after trying the proposed solution (removed line references, as these are exactly the same as OP):

Undefined symbols for architecture armv7:
  "vtable for std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >", referenced from:
  [...]
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "VTT for std::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >", referenced from:
  [...]
  "std::cerr", referenced from:
  [...]
  "std::string::assign(std::string const&)", referenced from:
  [...]      
  "std::ios_base::Init::~Init()", referenced from:  
  [...]
  "std::_Rb_tree_decrement(std::_Rb_tree_node_base*)", referenced from:
  [...]
  "std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)", referenced from:
  [...]
  "std::ostream::flush()", referenced from:
  [...]
  "std::basic_ios<char, std::char_traits<char> >::widen(char) const", referenced from:
  [...]
  "std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char)", referenced from:
  [...]
  "vtable for std::basic_streambuf<char, std::char_traits<char> >", referenced from:
  [...]
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "std::basic_ios<char, std::char_traits<char> >::clear(std::_Ios_Iostate)", referenced from:
  [...]
  "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&)", referenced from:
  [...]
  "std::istream& std::istream::_M_extract<unsigned int>(unsigned int&)", referenced from:
  [...]
  "std::cout", referenced from:
  [...]
  "std::_Rb_tree_increment(std::_Rb_tree_node_base*)", referenced from:
  [...]
  "std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int)", referenced from:
  [...]
  "std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)", referenced from:
  [...]
  "std::ios_base::Init::Init()", referenced from:
  [...]
  "std::string::find_first_of(char const*, unsigned long, unsigned long) const", referenced from:
  [...]
  "std::ostream::operator<<(int)", referenced from:
  [...]
  "std::string::compare(char const*) const", referenced from:
  [...]
  "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&, unsigned long, unsigned long)", referenced from:
  [...]
  "std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long)", referenced from:
  [...]
  "std::string::_Rep::_M_destroy(std::allocator<char> const&)", referenced from:
  [...]
  "std::string::_Rep::_S_empty_rep_storage", referenced from:
  [...]
  "std::locale::~locale()", referenced from:
  [...]
  "std::basic_istringstream<char, std::char_traits<char>, std::allocator<char> >::basic_istringstream(std::string const&, std::_Ios_Openmode)", referenced from:
  [...]
  "std::__throw_length_error(char const*)", referenced from:
  [...]
  "std::__throw_out_of_range(char const*)", referenced from:
  [...]
  "std::ostream& std::ostream::_M_insert<double>(double)", referenced from:
  [...]
  "std::istream::operator>>(int&)", referenced from:
  [...]
  "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)", referenced from:
  [...]
  "std::ostream::put(char)", referenced from:
  [...]
  "std::ios_base::~ios_base()", referenced from:
  [...]
  "std::istream::get()", referenced from:
  [...]
  "std::istream& std::istream::_M_extract<float>(float&)", referenced from:
  [...]
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Thanks!

Hi JBL

Of the three things you tried, the approach we suggest is the second one:

• Adding the path to libstdc++.dylib in the "Other Linker Flags"

Please can you post the linker errors, before and after making this change? and then we can investigate further.

BTW The third approach will not work because Apple do not support any version of GCC after 4.2.  It has to be the copy of libstdc++ that is included in Xcode.

cheers

N

What you are proposing to do is not a good idea actually because of big difference in implementations of C++ standard libraries. I'm not sure, but according to some guys smarter them me you would be asking for problems if linking to both (even if you manage such configuration to work somehow)... Look here for example: http://stackoverflow.com/questions/12542971/using-libstdc-compiled-libraries-with-clang-stdlib-libc

So, again. We need two versions of Vuforia library : one linked to libstdc++ (iOS 4 and up) and one linked to libc++ (iOS 5 and up)

This situation cannot be resolved with any configurational hacks on a client side in general case (for example if you use std::string somewhere) untill we have access to source code of course :)

Tell me if I'm wrong and correct those smart guys on stackoverflow if you have more information, please

Regards

Hi!

I just faced this very issue, with the exact same linker errors as the OP.

I tried different ways to link with both libs, including your proposed solution, but that hasn't fixed the issue, I'm still getting the linker errors.

What I tried:

• Adding libstdc++.dylib in "Build phase > Link Binary with Libraries"
• Adding the path to libstdc++.dylib in the "Other Linker Flags"
• Adding the path to the libstdc++.dylib of a fresh installation of gcc 4.9.0

Neither worked, so I'd like to know if you have another solution to fix this problem. I compile/link with the following (relevant) flags:

• C++ Language Dialect = C++ 11 (-std=c++11)
• C++ Standard Library  = libc++ (LLVM standard library with c++11 support)

Thanks in advance!

JBL

Ok, I checked with the Development Team and this ought to work.

Essentially you should be able to get this working by linking with both STLs which should be possible.

In Build Settings in XCode you can leave the setting for "C++ Standard Library" set for C++11.

Then under "Other Linker Flags" put the path of the libstdc++ library.  For example on iOS SDK 7.1 this would be /Applications/Xcode_511.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/usr/lib/libstdc++.dylib

Try this and let me know whether it resokved the linker errors.

thanks

N

+1

Haveing the same problem. Currently have to stay at 2.8.x :(

+1 to libc++ linkage

I've been using 2.8.3 previously with my C++11 code and everything worked like a charm. With the new 3.0.5 build my app now fails to link due to the same issues like topicstarter have.