Crash due to missing symbols from libc++ [macOS 11.7.10] [Big Sur]

Programming Languages General
ameydalvi OP
Created Oct ’24
Replies 5
Boosts 0
Views 489
Participants 3

We are seeing a crash on Big Sur 11.7.10 after switching the build system to use Xcode 15

Excerpt from crash

Time Awake Since Boot: 1700 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x4] Symbol missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Symbol not found: __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE
  Referenced from: /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon
  Expected in: /usr/lib/libc++.1.dylib
 in /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon

Build system has the following specs :

ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60

Xcode 15.2 Build version 15C500b

CMAKE PROPS

  • set(CMAKE_CXX_STANDARD 20)
  • set(CMAKE_CXX_EXTENSIONS OFF)
  • set(CMAKE_OSX_DEPLOYMENT_TARGET 11.0)
Answered by DTS Engineer in 812389022

Thanks for that. It confirms that your main executable is built correctly, that is:

  • It’s using the macOS 14.2 SDK:

          sdk 14.2

  • With a deployment target of macOS 11:

        minos 11.0

Comparing the macOS 11.3 and macOS 12.0 SDKs, I see that __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE is present in the latter and not in the former. That suggests that this symbol was added in macOS 12, and hence the failure you’re seeing.

Demangling the symbol I see:

% c++filt __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE
std::__1::codecvt<char32_t, char8_t, __mbstate_t>::id

So, we’re talking about the converter from char32_t to char8_t. Digging through the SDKs again, I see that the equivalent symbol is present for other conversions, including:

// macOS 11.3 SDK

std::__1::codecvt<char32_t, char, __mbstate_t>::id
std::__1::codecvt<char16_t, char, __mbstate_t>::id
std::__1::codecvt<char, char, __mbstate_t>::id
std::__1::codecvt<wchar_t, char, __mbstate_t>::id

// macOS 12 SDK

std::__1::codecvt<char32_t, char, __mbstate_t>::id
std::__1::codecvt<char16_t, char, __mbstate_t>::id
std::__1::codecvt<char, char, __mbstate_t>::id
std::__1::codecvt<wchar_t, char, __mbstate_t>::id
std::__1::codecvt<char32_t, char8_t, __mbstate_t>::id       <<< new
std::__1::codecvt<char16_t, char8_t, __mbstate_t>::id       <<< new

So it seems that macOS 12 added char8_t support.

I see two options here:

  • Raise your deployment target to macOS 12.

  • Modify your code to not rely on the char8_t converter.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  5
Boosts  0
Views  489
Participants  3
MobileTen OP
Oct ’24

ProductName: macOS ProductVersion: -->14.3.1<-- BuildVersion: 23D60 - Upgrading the OS is required.

0
DTS Engineer OP
Apple
Nov ’24

Xcode 15 should be able to target macOS 11. For info on which Xcodes ship with with SDKs and where you can run them, see Developer > Support > Articles > Xcode.

If you run the following command after seeing the crash, what do you get back:

% vtool -show /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
ameydalvi OP
Nov ’24

@DTS Engineer

Output of vtool command on macOS 11.7.10

/Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon (architecture x86_64):
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 14.2
   ntools 1
     tool LD
  version 907.0
Load command 11
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
/Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon (architecture arm64):
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 14.2
   ntools 1
     tool LD
  version 907.0
Load command 11
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
0
DTS Engineer OP
Apple
Nov ’24
Accepted Answer
Recommended

Thanks for that. It confirms that your main executable is built correctly, that is:

  • It’s using the macOS 14.2 SDK:

          sdk 14.2

  • With a deployment target of macOS 11:

        minos 11.0

Comparing the macOS 11.3 and macOS 12.0 SDKs, I see that __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE is present in the latter and not in the former. That suggests that this symbol was added in macOS 12, and hence the failure you’re seeing.

Demangling the symbol I see:

% c++filt __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE
std::__1::codecvt<char32_t, char8_t, __mbstate_t>::id

So, we’re talking about the converter from char32_t to char8_t. Digging through the SDKs again, I see that the equivalent symbol is present for other conversions, including:

// macOS 11.3 SDK

std::__1::codecvt<char32_t, char, __mbstate_t>::id
std::__1::codecvt<char16_t, char, __mbstate_t>::id
std::__1::codecvt<char, char, __mbstate_t>::id
std::__1::codecvt<wchar_t, char, __mbstate_t>::id

// macOS 12 SDK

std::__1::codecvt<char32_t, char, __mbstate_t>::id
std::__1::codecvt<char16_t, char, __mbstate_t>::id
std::__1::codecvt<char, char, __mbstate_t>::id
std::__1::codecvt<wchar_t, char, __mbstate_t>::id
std::__1::codecvt<char32_t, char8_t, __mbstate_t>::id       <<< new
std::__1::codecvt<char16_t, char8_t, __mbstate_t>::id       <<< new

So it seems that macOS 12 added char8_t support.

I see two options here:

  • Raise your deployment target to macOS 12.

  • Modify your code to not rely on the char8_t converter.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1
ameydalvi OP
Nov ’24

Thanks for the analysis. That really helps, actually the symbol was referenced from one of the third party libs we are using.

Will try to see if we can move away from the current version of the lib

0
Crash due to missing symbols from libc++ [macOS 11.7.10] [Big Sur]
First post date Last post date
 
 
Q