Cannot get App built on OS X 10.9 to run on OS X 1

Problem

I've recently upgraded my build environment to Xcode 6.1.1, running on OS X 10.9, and now I'm having trouble getting my application running again under OS X Leopard, 10.5.

For the target, Base SDK is set to OS X 10.6, and OS X Deployment Target is set to OS X 10.5. Inspecting the build logs shows that these settings are making their way through to the compilation and link phases (in the form of mmacosx-version-min=10.5, export MACOSX_DEPLOYMENT_TARGET=10.5, etc.)

However, when I run the application under OS X 10.5, it crashes immediately with the error:

Dyld Error Message:
  Symbol not found:    __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE9showmanycEv
  Referenced from: /[path]/[Application Name].app/Contents/MacOS/[Application Name]
  Expected in: /usr/lib/libstdc++.6.dylib

What I've Tried So Far

A bit of digging around shows that on OS X 10.9, /usr/lib/libstdc++.6.dylib is a link to version 6.0.9, and on OS X 10.5 it's a link to version 6.0.4.

Other questions on SO suggest that the answer is to include a copy of the required version of libstdc++.6.dylib in the app bundle, and to point the dynamic linker to it using install_name_tool.

So I run the command:

install_name_tool -change /usr/lib/libstdc++.6.dylib @executable_path/libstdc++.6.dylib [Application Name].app/Contents/MacOS/[Application Name]

And otool -L [Application Name].app/Contents/MacOS/[Application Name] now reports:

@executable_path/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)

I copy /usr/lib/libstdc++.6.0.9.dylib to the location [Application Name].app/Contents/MacOS/libstdc++.6.dylib and copy the application over onto the deployment machine and get...

Dyld Error Message:
  Symbol not found:    __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE9showmanycEv
  Referenced from: /[path]/[Application Name].app/Contents/MacOS/[Application Name]
  Expected in: /usr/lib/libstdc++.6.dylib

...exactly the same error message.

Running otool -L on the application on the deployment machine confirms that the link to libstdc++.6.dylib is still pointing to the path under @executable_path that I set up with install_name_tool.

So why is the dynamic linker ignoring the path set up by install_name_tool and still looking in /usr/lib?

Is this the correct solution for the problem?