4

I'm trying to port a project of mine on Mac OS-X.

As I developed my project using C++0X I needed a more recent version of GCC than the one provided with Xcode (even Xcode4), so I compiled GCC 4.6 on my Snow Leopards Mac.

My project does compile fine and it does start too on the computer I compiled it (OS-X 10.6.7) but when I transfer it to my MacBook (OS-X 10.5.8) it doesn't works.

It returns the following errors:

dyld: lazy symbol binding failed: Symbol not found: __ZNSo9_M_insertImEERSoT_ Referenced from: /Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp Expected in: /usr/lib/libstdc++.6.dylib

dyld: Symbol not found: __ZNSo9_M_insertImEERSoT_ Referenced from: /Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp Expected in: /usr/lib/libstdc++.6.dylib

I understand that the program needs the libstdc++.6.dylib of the GCC 4.6.0 as this file contains the C++0x functions (despite the fact that my current test doesn't use any C++0x function) instead of the standard libstdc++.6.dylib usually included in the OS-X system.

So I tried the following:

  • to specify -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 in order to ensure backward compatibility with OS-X 10.5. But the error remains the same.

  • to verify the libstdc++.6.dylib path using otool -L and changing the shared library path using install_name_tool -change /opt/local/lib/gcc46/libstdc++.6.dylib @executable_path/../Libraries/libstdc++.6.dylib OgreApp (with a copy of the gcc 4.6.0 libstdc++.6.dylib in the Libraries folder) as suggested as answer of my previous question. But the error remains the same.

  • to statically link libstdc++ and libgcc using -static-libgcc - static-libstdc++. But it still returns the same error.

As my program use the Ogre framework, I applied the above manipulations to the Ogre executable embedded in the Ogre.framework too, but it doesn't change anything.

Does anyone can explain me how I'm supposed to deploy an application created with a non standard libstdc++ on another Mac computer installed with an older version (I guess the problem is the same with a computer running Snow Leopard as the program use the GCC 4.6.0 libstdc++) ?

Community
  • 1
  • 1
Valkea
  • 1,216
  • 1
  • 12
  • 26
  • This is an exact duplicate of a question *YOU* Valkea asked a week ago. – Grant Limberg Jun 22 '11 at 17:39
  • possible duplicate of [Unable to run an application compiled on OS-X Snow Leopard (10.6.7) on another Mac using OS-X Leopard (10.5.8). libstdc++.6.dylib error returned.](http://stackoverflow.com/questions/6365772/unable-to-run-an-application-compiled-on-os-x-snow-leopard-10-6-7-on-another-ma) – Grant Limberg Jun 22 '11 at 17:39
  • This is not a duplicate this is the consequence of the other question as I indicated in THIS question. I made researches around the suggested answer on the other thread and I now expose my new point of view of this problem here. – Valkea Jun 22 '11 at 17:41
  • Did you verify with `otool` that your `install_name_tool` change actually did anything? I ask because normally (i.e., on other Unix systems) the shared library name is stored in the exectuable in short form (like "libstdc++.6.dylib"), not as a full path... And the executable's `rpath` is searched to locate it. In other words, I think you need to use `install_name_tool -rpath ...` instead of `install_name_tool -change`. – Nemo Jun 22 '11 at 17:52
  • @Nemo : well it did changed when I asked otool -L to print after changing it with install_name_change -change, but I will give a try to your suggestion (-rpath). – Valkea Jun 22 '11 at 18:00

1 Answers1

0

Mac OS X 10.5 does not include a compatible copy of the GCC standard library. If you want your code to run on Leopard, you'll have to either modify it to compile under an older version of GCC, or you'll have to... well, really that's your only option.

Jonathan Grynspan
  • 43,286
  • 8
  • 74
  • 104