OS X程序在开发机上运行，​​在其他计算机上严重崩溃 [英] OS X program runs on dev machine, crashing horribly on others

问题描述

我有一台OS X 10.6 Mac，正在用作我的开发机器.我编写的程序在dev机器上可以完美运行.但是，当我尝试在OS X 10.5(不确定是否相关)测试计算机上运行它时，它在启动时崩溃.

I have an OS X 10.6 Mac I'm using as my dev machine. The program I wrote works perfectly on the dev machine. However, when I tried to run it on an OS X 10.5 (not sure if that's relevant) test machine, it crashes on launch.

这是我得到的错误:

Process:         MyApp[25908]
Path:            /Applications/MyApp.app/Contents/MacOS/MyApp
Identifier:      MyApp
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  launchd [109]

Interval Since Last Report:          17392106 sec
Crashes Since Last Report:           735
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   8

Date/Time:       2010-08-14 07:50:09.768 -0700
OS Version:      Mac OS X 10.5.8 (9L31a)
Report Version:  6
Anonymous UUID:  1BF30470-ACF2-46C7-B6D5-4514380965C8

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Dyld Error Message:
  Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i
  Referenced from: /Applications/MyApp.app/Contents/MacOS/MyApp
  Expected in: /usr/lib/libstdc++.6.dylib

所以看起来好像是崩溃了，因为它正在加载动态库libstdc ++.6的不兼容版本.这种事情很普通吗?在Google上进行搜索并不能真正揭示出很多其他有此问题的程序.为了防止这种情况发生，我在编译时应该做什么?我需要以某种方式在应用程序包中包含libstdc ++吗?

So it looks like it's crashing because it's loading an incompatible version of the dynamic library libstdc++.6. Is this type of thing ordinary? A search on Google doesn't really reveal many other programs that have this problem. What should I be doing in my compile to prevent this from happening? Do I need to be somehow including libstdc++ inside of my application bundle?

推荐答案

此问题的解决方案是将以下代码添加到您的一个源文件中:

The solution to this problem is to add the following code to one of your source files:

// Workarounds for symbols that are missing from Leopard stdlibc++.dylib.
_GLIBCXX_BEGIN_NAMESPACE(std)
// From ostream_insert.h
template ostream& __ostream_insert(ostream&, const char*, streamsize);

#ifdef _GLIBCXX_USE_WCHAR_T
    template wostream& __ostream_insert(wostream&, const wchar_t*, streamsize);
#endif

// From ostream.tcc
template ostream& ostream::_M_insert(long);
template ostream& ostream::_M_insert(unsigned long);
template ostream& ostream::_M_insert(bool);
#ifdef _GLIBCXX_USE_LONG_LONG
    template ostream& ostream::_M_insert(long long);
    template ostream& ostream::_M_insert(unsigned long long);
#endif
template ostream& ostream::_M_insert(double);
template ostream& ostream::_M_insert(long double);
template ostream& ostream::_M_insert(const void*);

#ifdef _GLIBCXX_USE_WCHAR_T
    template wostream& wostream::_M_insert(long);
    template wostream& wostream::_M_insert(unsigned long);
    template wostream& wostream::_M_insert(bool);
    #ifdef _GLIBCXX_USE_LONG_LONG
        template wostream& wostream::_M_insert(long long);
        template wostream& wostream::_M_insert(unsigned long long);
    #endif
    template wostream& wostream::_M_insert(double);
    template wostream& wostream::_M_insert(long double);
    template wostream& wostream::_M_insert(const void*);
#endif

// From istream.tcc
template istream& istream::_M_extract(unsigned short&);
template istream& istream::_M_extract(unsigned int&);  
template istream& istream::_M_extract(long&);
template istream& istream::_M_extract(unsigned long&);
template istream& istream::_M_extract(bool&);
#ifdef _GLIBCXX_USE_LONG_LONG
    template istream& istream::_M_extract(long long&);
    template istream& istream::_M_extract(unsigned long long&);
#endif
template istream& istream::_M_extract(float&);
template istream& istream::_M_extract(double&);
template istream& istream::_M_extract(long double&);
template istream& istream::_M_extract(void*&);

#ifdef _GLIBCXX_USE_WCHAR_T
    template wistream& wistream::_M_extract(unsigned short&);
    template wistream& wistream::_M_extract(unsigned int&);  
    template wistream& wistream::_M_extract(long&);
    template wistream& wistream::_M_extract(unsigned long&);
    template wistream& wistream::_M_extract(bool&);
    #ifdef _GLIBCXX_USE_LONG_LONG
        template wistream& wistream::_M_extract(long long&);
        template wistream& wistream::_M_extract(unsigned long long&);
    #endif
    template wistream& wistream::_M_extract(float&);
    template wistream& wistream::_M_extract(double&);
    template wistream& wistream::_M_extract(long double&);
    template wistream& wistream::_M_extract(void*&);
#endif

_GLIBCXX_END_NAMESPACE

潜在的问题是，在libstdc ++标头中有多个模板被声明为extern模板，尽管它们的实例化是由10.6+上的libstdc ++提供的，但它们却不是由10.5+上的libstdc ++提供的.结果，当您使用这些模板时，您成功地链接了10.6 SDK，以实现10.5 OS所不提供的功能，因此dyld在启动时就没有了.通过自己提供实例，可以确保代码将加载到Snow Leopard上.

The underlying issue is that there are several templates that are declared as extern templates in libstdc++ headers, and while their instantiations are provided by libstdc++ on 10.6+, they are not provided by the libstdc++ on 10.5. As a result, when you are using these templates, you wind up successfully linking against the 10.6 SDK for functions not provided by the 10.5 OS, and so dyld craps out on launch. By providing the instantiations yourself, you ensure your code will load on Snow Leopard.

或者，您可以

#define _GLIBCXX_EXTERN_TEMPLATE 0 

在您的前缀文件中，但是这样做会导致模板代码膨胀.

in your prefix file, but doing so will cause template code bloat.

这篇关于OS X程序在开发机上运行，​​在其他计算机上严重崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！