Geek Answers Handbook

Failed to start application compiled on OS-X Snow Leopard (10.6.7) on another Mac using OS-X Leopard (10.5.8). libstdc ++. 6.dylib error.

I am trying to port a C ++ project using C ++ 0x and Ogre to Max OS-X, and I am facing portability issue between OS-X versions.

I managed to build my project on Mac OS-X 10.6 (Snow Leopard) using GCC 4.6.0 (because I need C ++ 0x). It was difficult (maybe because I'm a new OSX user), but he finally compiled it without errors.

I have included all the necessary Components, Frames, Plugins, etc. required in the Application.app package, and it works fine on this Mac OS-X 10.6

But when I transfer the project to my old laptop installed with Mac OS-X 10.5.8, I can not start the application.

If I double-clicked .app, try starting, and finally the icon disappears from the menu bar and that’s it. But if I run the executable file included in the .app directly, it returns the following errors:

MacBook-2:~ root# /var/root/Desktop/MyProject.app/Contents/MacOS/MyProject ; exit; dyld: lazy symbol binding failed: Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i Referenced from: /var/root/Desktop/MyProject.app/Contents/MacOS/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre Expected in: /usr/lib/libstdc++.6.dylib dyld: Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i Referenced from: /var/root/Desktop/MyProject.app/Contents/MacOS/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre Expected in: /usr/lib/libstdc++.6.dylib Trace/BPT trap logout

Here is a view of the application package tree.

Myproject.app

  • Components
    • ... (Ogre components)
  • Wireframes
    • Ogre.framework
  • MacOS
    • MyProject (executable file)
  • Plugins
    • ... (Ogre plugins)
  • Resources
    • ... (Ogre.cfg + my assets)

I told Cmake to use MacOSX10.5.sdk using (installed inside the Cmake GUI, not inside CMakeList.txt):

  • CMAKE_OSX_DEPLOYEMENT_TARGET 10.5
  • CMAKE_OSX_SYSROOT / Developer / SDKs / MacOSX10.5.sdk

But it does not change anything...

The file libstdc ++. Dylib, links to libstdc ++. 6.0.9.dylib on Mac, used to compile the application, whereas it refers to libstdC ++. 6.0.4.dylib on Mac, used to test portability.

But since I told him to use MacOSX10.5.sdk, I would use libstdC ++. 6.0.4.dylib at compile time, so it can run on a Mac installed with 10.5

In fact, the goal is to make it work on a second Mac (and all Macs using 10.5+) without changing anything on it. Just download and run ...

Can someone tell me what I'm missing here? (I really don’t feel at ease with the methods and organization of OS-X, so I could have missed something very simple, not the fear of being rude ^^).

How to specify target SDK in Cmake? (Are Cmake Commands Used?)

To compile my project, I use the following:

  • Mac OS-X 10.6.7
  • GCC 4.6.0
  • Cmake 2.8-4
  • Ogre 1.7.3

To test the project, I use the following:

  • Mac OS-X 10.5.8 (there are some tools for developers. I think I should say this if this can interfere with applications).

Edit:

Since I discovered otool, the log is returned here

 Valkeas-Mac:MacOS root# otool -L MyProject MyProject: @executable_path/../Frameworks/Ogre.framework/Versions/1.7.3/Ogre (compatibility version 0.0.0, current version 1.7.3) @executable_path/../Components/libOgreTerrain.dylib (compatibility version 0.0.0, current version 1.7.3) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 136.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /opt/local/lib/gcc46/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.15.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/gcc46/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.54.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.26.0) Valkeas-Mac:MacOS root#

Obviously, it refers to gcc46 libstdc ++. 6.dylib (possibly normal, as I assume this file contains C ++ 0x functions from GCC 4.6.0).

So is there any solution? (-static returns an error indicating that I need a dynamic ...)

+4
source share
2 answers

The libstdc++ is gcc 4.6. Since you are using C ++ 0x, which is not available in the gcc version that ships with OS X, it is not surprising that the built-in libstdc++ does not work. You need to send libstdc++.dylib , which you use inside your application package (you can put it, for example, in your.app/Contents/Libraries). Use install_name_tool to make sure it is referenced using a relative path (use @rpath or @executable_path ).

+4
source

Although the chosen answer is probably more practical for many, this is actually a bug in the Apple toolchain, which is trivially fixed with a very small patch. Of course, it is wrong to blame the problem for using C ++ 0x or even blame the problem for using different versions of gcc: this stuff should usually work. Given how many people seem to be experiencing this problem as users (judging by a Google search), we hope this can be fixed upstream in Xcode 5.1 (although given the smug response I received from Apple in the past regarding simple five-minute fixes to better maintain backward compatibility, I'm not holding my breath, I'm going to file a radar, no matter how I think it's really important). The fix is ​​to change the ostream header to add protective __TARGETING_4_0_DYLIB around the <implementation for strings operator. I posted the patch on my website at http://test.saurik.com/apple/ostream1.diff .

+1
source

More articles:


All Articles