Undefined symbols for architecture error when deployment target is 7.0

Guven picture Guven · Oct 9, 2013 · Viewed 11.4k times · Source

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.

Answer

Denis picture Denis · Apr 2, 2014

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