当前位置： 文江博客话题详情

OS X 程序在开发机器上运行，在其他机器上严重崩溃

发布于 2024-09-14 12:14:29 字数 1172 浏览 6 评论 0原文

我有一台 OS X 10.6 Mac 作为我的开发机器。我编写的程序在开发机器上完美运行。然而，当我尝试在 OS X 10.5（不确定这是否相关）测试机上运行它时，它在启动时崩溃了。

这是我收到的错误：

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++ 包含在我的应用程序包中？

原文

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.

This is the error I'm getting:

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

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?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（3）

爱*していゐ 2024-09-21 12:14:29

此问题的解决方案是将以下代码添加到源文件之一：

// 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 操作系统未提供的功能，因此 dyld 在启动时会崩溃。通过您自己提供实例，您可以确保您的代码能够在 Snow Leopard 上加载。

或者，您可以

#define _GLIBCXX_EXTERN_TEMPLATE 0

在前缀文件中添加，但这样做会导致模板代码膨胀。

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

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.

Alternately, you can

#define _GLIBCXX_EXTERN_TEMPLATE 0

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

回复 原文
薄荷梦 2024-09-21 12:14:29

我能想到的有几点：

  1. 您是否将其编译为“发布版本”？调试版本可能无法在编译它的机器以外的机器上运行。

  2. 您使用的是哪个 SDK？您在构建设置中指定了哪个最低操作系统版本？如果您想在 10.5 上运行它，您需要使用 10.5 SDK 和/或将目标操作系统设置为 10.5。请参阅 此 Apple 文档关于针对多个操作系统版本进行构建。

  3. 目标机器是否将DYLD_LIBRARY_PATH设置为非空？如果不小心操作，可能会混淆dyld。

区分各种可能性的一种方法是在开发计算机中运行您的应用程序，但使用一个独立的帐户，该帐户没有开发帐户的管理员权限；然后你可以测试它是否在10.6盒子中运行。

There are a few points I can think of:

  1. Did you compile it as a "release build"? The debug build might not run on machines other than the one in which it is compiled.

  2. Which SDK did you use? Which minimal OS version did you specify in the build settings? If you want to run it on 10.5, you need to use 10.5 SDK and/or set the target OS to be 10.5. See this Apple document on building for multiple OS versions.

  3. Did the target machine have DYLD_LIBRARY_PATH set to something non-empty? If not done carefully, that might confuse dyld.

One way to distinguish various possibilities is to run your app in the dev machine, but with a separate account with no admin privilege from the dev account; then you can test whether it runs in an 10.6 box.

回复 原文
十年九夏 2024-09-21 12:14:29

我遇到了同样的问题（使用 GCC 4.2 构建使我的代码无法在 OS X 10.5 上执行，因为 libstdc++.6.dylib 中出现 dyld 错误）。

Ben Artin 提出的解决方案有效。或者，您可以在添加任何标头之前将定义 _GLIBCXX_EXTERN_TEMPLATE 设置为零（如果您使用预编译标头，请确保它们是使用正确的定义集进行编译的）。

I ran into the same issue (building with GCC 4.2 makes my code unable to execute on OS X 10.5 because of dyld errors in libstdc++.6.dylib).

The solution proposed by Ben Artin works. Alternatively, you can set the define _GLIBCXX_EXTERN_TEMPLATE to zero before adding any headers (if you are using precompiled headers, make sure they are compiled with the define set correctly).

回复 原文
~没有更多了~

关于作者

慕巷

暂无简介

0 文章
0 评论
24 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

1CH1MKgiKxn9p

文章 0 评论 0

ゞ记忆︶ㄣ

文章 0 评论 0

JackDx

文章 0 评论 0

信远

文章 0 评论 0

yaoduoduo1995

文章 0 评论 0

霞映澄塘

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文