Undefined symbols for architecture error when deployment target is 7.0

23
votes

I am using third party frameworks in my native iOS application (bunch of .a libraries). My application is developed with XCode 5 base SDK 7.0.

The libraries compile and link fine when the deployment target is 6.1 (library and header search paths are good). However, when I change the deployment target to be 7.0, I get the following linker error:

Undefined symbols for architecture i386:
  "std::string::find_last_of(char const*, unsigned long) const", referenced from:
      GetExecutionDir(ECTemplateString<char>&, char*, bool) in myLibrary.a(moPlatForm.o)
  "std::string::find(char const*, unsigned long) const", referenced from:
      ParseLog(std::string const&, unsigned int&, CmoDateTime&, int&, std::string&) in myLibrary.a(AppLog.o)
  "std::string::size() const", referenced from:
      mo::CmoParam::WriteToStream(void*, mo::STREAM_STATE*) in myLibrary.a(moParams.o)
  "std::string::c_str() const", referenced from:
      GetExecutionDir(ECTemplateString<char>&, char*, bool) in myLibrary.a(moPlatForm.o)
      CMocaFileTransfer::UpdateParamsForGetTraceFiles(mo::CmoParamList&, long) in myLibrary.a(RobieFileTransfer.o)
      CMocaFileTransfer::AddTraceFileForUpload(std::string const&, std::string const&) in myLibrary.a(RobieFileTransfer.o)
      CMocaFileTransfer::CreateParamsForSendTraceFiles(mo::CmoObject&) in myLibrary.a(RobieFileTransfer.o)
      mo::CmoParam::WriteToStream(void*, mo::STREAM_STATE*) in myLibrary.a(moParams.o)
      ParseLog(std::string const&, unsigned int&, CmoDateTime&, int&, std::string&) in myLibrary.a(AppLog.o)
      CAppLog::LogExists(unsigned int) in myLibrary.a(AppLog.o)
      ...

Libraries are a bit old, I am not sure if there is a compatibility issue. I am not planning to support iOS 6 so I need to set the deployment target as 7.0. Any kind of help/direction would be great.

3
iphoneiosxcodeios7linker-errors
Any reason why these are getting compiled to i386? I'm guessing you need to remove i386 from the target build settings so only armv7 and armv7s is in there. – Justin
I have tried playing with the architectures. I don't think it is an architecture issue. By the way, libraries only support armv7, so armv7s is out of the question. – Guven
I hear ya, but at the very top of the error it says architecture i386. Apparently it doesn't support that either :-) – Justin
Thanks for the hint. I am also facing the same kind of errors from trying to link to third party c++ libraries (libjingle). My environment is Xcode 5.0 and deployment target iOS 7.0. I just switched to deployment target iOS 6.1 for time being and the errors are gone. I guess for deployment target iOS 7.0, you need to add an empty .mm file (as mentioned in the below answers but I will try that later). – Rajaraman

3 Answers

46
votes

for me, including the 'stdc++.6.0.9.dylib' instead of 'stdc++.dylib' into the dependencies resolved the linker errors too

28
votes

It turns out that if XCode can't find any C++ files in the project, then it assumes that libstd++ is not required. So, you have to manually add a C++ file to the project (an empty .mm file would be enough). That is the solution.

All the credits go to this answer in this Stackoverflow thread.

8
votes

It looks as if myLibrary.a was built with calls to C++ code and used libstdc++ as its C++ standard library. Your application project probably specifies libc++ instead, perhaps as the compiler default.

Try switching back to libstdc++ and see if the errors go away (or change, at least). Your eventual solution is likely to be a library that's built against the new standard library.